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. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
