Re: [Evolution-hackers] calendar EPlugin plans

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]