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 > email@example.com > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers