Re: [Evolution-hackers] calendar EPlugin plans

[Thomas Cataldo <thomas cataldo aliacom fr>]

On Fri, 2004-10-15 at 17:58 +0800, Not Zed wrote:
> Again, unrelated.  You shouldn't even be touching e-account-list at
> all, you only have to in 2.0 since it has no way to 'run' the code
> otherwise.  This stuff should all be configured directly on the
> e-source/e-source group. 

Ok, I didn't meant to be rude (really sorry if my email felt like some
flame). We will do our best to integrate correctly with the next evo
version _and_ the current evo version. My point was just about low level
technical stuff.

Right now we are registering sources with ebooks which looks like
obm://foofoofoo/EBook;XXX and YYY (I mean ....;YYY) and the ebook server
treats then different sources (good for us).
When we do the same thing with ecal sources and uris like
obm://foofoofoo/Calendar;xxx and obm://foofoofoo/Calendar;yyy they are
treated as the same calendar (only one cal to ....cal__open).
At first, looking at the groupwise backend I was a bit lost : they
register a "user" property on the ebook sources and a "username" one on
the cal sources. For me it looks like a string based API. We've got
something that works (for cal and books) but We have a great pain to
understand _why_ the sources stuff works for us. I'm not asking for
documentation because I think that a good API is auto-documented by the
method names/types, but I'm begging for less strings in the
constructors/methods in Esource stuff.

My understanding is that with the new EPlugin stuff we will be able to
plug into the "properties" of ecal sources and in the ecals creation
window.Our software grants one calendar for every user. One of the main
features of the web version of our software is to display "my" writable
calendar and some read-only cals of my co-workers calendars.

Porting to 2.2 seems like big jump/cleanup but we are trying to release
something before that.

Cheers,
Tom.