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

[Matthew Barnes <mbarnes redhat com>]

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().

  ECalBackendCache *
  e_cal_backend_cache_new (const gchar *filename);

  ECalBackendFileStore *
  e_cal_backend_file_store_new (const gchar *path);

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?