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

[Milan Crha <mcrha redhat com>]

[please reply to the list only, it makes my life worse when you CC me]

On Thu, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
> It would mean EClient has to know that ECalClient and EBookClient exist
> in order to instantiate the right one for a given enum value.  Normally
> in class design you want to avoid that kind of knowledge seeping into
> lower layers, but with the class hierarchy being fixed to these three
> classes (four if we add email), I think it's a good tradeoff to have a
> more consistent API.
> 
> So it would be something like:
> 
> typedef enum {
>     E_CLIENT_TYPE_ADDRESS_BOOK,
>     E_CLIENT_TYPE_CALENDAR,
>     E_CLIENT_TYPE_MEMO_LIST,
>     E_CLIENT_TYPE_TASK_LIST
> } EClientType;

You obviously face of a circular dependency, so it's not doable in a
clean way. Also because EClient is in libedataserver, EBookClient in
addressbook/libebook and similarly ECalClient in calendar/libecal. Both
descendants link to libedataserver... Having another
register_client/unregister_client function will make things only less
clear for readers (like if one tries to follow signal handlers by
reading the code.

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

This is partly fixed, as I faced of change inability of capabilities
too, so the EClient itself is caching capabilities until online state
changes. When it changes the client side capabilities cache is purged
and the new set of capabilities is queried on the next access of them.
I do not see any problem in an "exists/doesn't exist" (or better
"capable/incapable") state for this particular thing. They are
capabilities, after all.

For CalDAV's CTag similarity, it might worth new API, than moving it
exposed on the capability side (I understood you are proposing something
like that), but it's usually not supported by all backends, so even
you'll have a possibility, then I believe you'll end with a default
behaviour of returning "something changed" and you'll check items in an
old way, thus no benefit for it.

	Bye,
	Milan