Re: [Evolution-hackers] calendar EPlugin plans

[Not Zed <notzed ximian com>]

On Sat, 2004-10-16 at 02:14 +0200, Thomas Cataldo wrote:
> 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.
Sure, it's just this was a thread about eplugin, so the fact you need to hack stuff in in <= 2.0 isn't even related.

> 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.
I was just dealing with ESource today - and quite frankly, i'm surprised it works at all.  It has a LOT of issues, and most of the api's don't even work like you expect them to.  It looks pretty broken to me.  Even the method names aren't very consistent and there is even some almost-but-not-quite duplication.

In camel we have to supply a uri compare function - since different backends have a different idea of what a different uri actually means.  e.g. some properties (which in camel are not separate from the base uri), are only mode changes and don't reference a different backend, like say a port change does.

ESource doesn't have this, and it also adds its own 'properties' separate from the base url.  It doesn't do proper relative-uri calculations.  It doesn't seem to do proper uri calculations as a rule.  There is no consistency in the way authentication info is specified, etc etc.

So it seems it is up to each backend to define whatever it needs.  And somehow it works with hacks at each end of the code to make it work - which doesn't help if you're trying to do things just from one side.
> 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.
Well the patch that started this thread had the code.  It should be possible to customise much/if/not/all of the properties/new calendar windows with whatever widgets and setup code you need.
> Porting to 2.2 seems like big jump/cleanup but we are trying to release
> something before that.
Yeah, obviously 2.2 is a bit of a way off (hmm, 5-6 months and falling).

--

Michael Zucchi <notzed ximian com> "born to die, live to work, it's all downhill from here" Novell's Evolution and Free Software Developer