Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds

[Patrick Ohly <patrick ohly gmx de>]

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 Ohly gmx de
http://www.estamos.de/