On Mi, 2011-05-04 at 14:37 +0200, Milan Crha wrote: > Hi, > I'm getting slightly lost what is left and what is under discussion, > thus please let me summarize things here: > > On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: > > First of all, +1 for rethinking the API. I'd like to suggest that > > besides modernizing the API we also take this opportunity to move more > > of EBook/ECal into a common core. > > It seems strange to me to have EClientSourceType defined in e-client.h > and its main usage in other file (remember of compiler dependency > issue), thus I suggest to keep e-client/e-book-client/e-cal-client as > they are and rename e-client-authentication.h/.c (which resides in > libedataserverui) to e-client-utils.h/.c and do common "interfaces" > here. This is including also e_client_open_new() being defined here. > This is for client-side code merging.
I still think that "list and open databases" are common operations and that having different libraries and code for contacts and calendar is a historic artifact. But let's not get hung up on that and move on without changing it. > > Talking of capabilities, I found their usefulness a bit limited > > because they a) cannot change during the life time of a client and > > b) they only report "exists/doesn't exit". > > Here was suggested a common e_client_get_property_sync (EClient *client, > const gchar *in_name, gchar **out_value, ...); function (with its async > equivalent) (the e_client_get_backend_property_sync is better > descriptive, less confusing with GObject properties, I guess, though > it's quite long name). I'm fine with that, I can add it. Thanks. > > Setting values should also be allowed. That gives us a way how > > a client can configure the storage to behave in certain ways. > > This can be per-database (tweak the actual on-disk storage) > > or per EClient (modify behavior as part of current session). > > This breaks abstraction, from my point of view. The client may not > know/expect anything about backends, That's not quite true in all cases. On an embedded system, a client might know exactly that it is going to be installed together with a specific backend and may want to influence that backend without having to maintain a non-upstream API for it. > so any property setting from client > side is not needed. Another situation would be a writable property that is supported by one or more backends. Writing in a backend which doesn't support should trigger an error, but in others it may make sense. For example, setting the color of a calendar is possible in CalDAV. A read/write property would make sense to expose that to clients. > You can ask for "change" tag, or "last modified" > tag, but you should not be able to change it from client side in other > than _add/_modify/_remove way. "change" and "last modified" would be read-only. But other properties may be writable. Even if there are none predefined now, adding the API now is necessary to make it future-proof. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers