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

[Milan Crha <mcrha redhat com>]

	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.

We opened also a question of server-side merging (mainly merge factory
and views into one base object and change only minimal parts (like dbus
service names and backend types) in descendants. I can either postpone
this, or do it before merging to master, though this is another big
step.

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

> 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, so any property setting from client
side is not needed. 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.

----------------------------------------------------------------

So here left basically three things,
   a) merging some API in utils,
   b) getting well-known properties,
   c) setting well-known properties
and all are sorted out, I guess. Thinking of well-known properties, I
would include other already used there too, like the "cache-dir",
"cal-email-address", "alarm-email-address", as these are just
properties, only each has its own API, which is unnecessary.

Is everyone fine with the above? (Note it's just my feeling about result
of the discussions, which can be particularly wrong in any way.)
	Thanks and bye,
	Milan