Re: [Evolution-hackers] Couple new functions for ECal/EBook

[chen <pchenthill novell com>]

On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote:
> On Mon, 2010-07-19 at 09:10 +0200, Milan Crha wrote:
> > that's a part which should be changed. The ideal way, as I understand
> > it, is to have an ECalBackend function to retrieve a path for
> > attachments, and ECal should ask backend for it, instead of duplicating
> > the code (it sort of blocks extendibility of ECalBackend, because the
> > client side depends on the code in evolution-data-server itself, which
> > is kinda wrong).
> > 
> > It will be good to fix this and move functions to libedata-book/cal,
> > where they, as you said, belong anyway.
> 
> I took Milan's advice and attempted to do this The Right Way... I think.
> 
> Here's what's changed:
> 
> Instead of adding standalone functions, I added a "cache-dir" property
> along with the usual get/set functions to EBookBackend and ECalBackend.
> The property is read/write, but the default value should rarely be
> overwritten (currently only the file backends override it).
> 
>   const gchar * e_book_backend_get_cache_dir (EBookBackend *backend);
>   void          e_book_backend_set_cache_dir (EBookBackend *backend,
>                                               const gchar *cache_dir);
> 
>   const gchar * e_cal_backend_get_cache_dir  (ECalBackend *backend);
>   void          e_cal_backend_set_cache_dir  (ECalBackend *backend,
>                                               const gchar *cache_dir);
> 
> Also I slightly broke the API of ECalBackendCache and ECalBackendStore
> to take a cache file name or cache directory name (respectively) instead
> of a URI and ECalSourceType, since the URI and ECalSourceType are only
> used to build a cache file name or cache directory name.
> 
> Backends using these classes can easily construct a suitable cache file
> or directory name from e_cal_backend_get_cache_dir().
get_cache_dir can simply return e_cal_backend_store_get_path.

> 
>   ECalBackendCache *
>   e_cal_backend_cache_new (const gchar *filename);
> 
>   ECalBackendFileStore *
>   e_cal_backend_file_store_new (const gchar *path);
Is it required ? Having it in ECalBackendStore simplifies the backend
code to form the path based on the type (calendar,tasks,memos) at a
single place rather than every backend doing it..

> 
> So now the name of a backend's base cache directory is centralized in
> its base class.  That takes care of the server side.
> 
> For the client side I added a simple ECal D-Bus method getCacheDir(),
> which does what it says.  ECal still caches the directory internally, so
> the method will only be called once per ECal instance.
> 
> I did not add a similar D-Bus method to EBook because there's currently
> no need for it, but we could easily add it later if desired.
> 
> How does this sound?  Any objections to the minor API break in the
> backend libraries?
Btw we could deprecate ECalBackendCache and update just
ECalBackendStore. 


- Chenthill.
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers