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

[Patrick Ohly <patrick ohly gmx de>]

On Do, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
> [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.

Agreed, the library dependency issue is a problem. That could be solved
by an utility library on top of libecal and libebook which offers the
unified API. In that case we wouldn't get rid of the special-purpose
calls in libecal and libebook, though, would we?

What about merging libebook and libecal into one shared library instead?
Evolution 3.2 will require an soname bump and source code changes in
apps anyway, throwing a renaming of libs into the mix won't make a big
difference.

I think it would make the overall API a lot cleaner, albeit with
slightly (?) higher memory footprint for apps which only need one or the
other.

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

And how does it know that capability changes cannot occur at some other
point in time? That sounds like it might work for the current set of
capabilities, but not like a general solution to the problem.

> 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 a capability like "how many events per calendar do you support" (can
be queried for CalDAV, if I remember correctly) a single bit is not
enough.

> 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),

A dedicated API just for CTag would have the problem that I mentioned
before: can only be used if the app is compiled against an EDS version
which has that call.

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

Even if it only works with a few backends it would be an improvement for
users of those backends and worthwhile in those cases, in particular if
the file backend supports it.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/