Re: [Evolution-hackers] calendar EPlugin plans

[Thomas Cataldo <thomas cataldo aliacom fr>]

On Thu, 2004-10-14 at 09:01 +0800, Not Zed wrote:
> On Wed, 2004-10-13 at 01:34 -0600, David Trowbridge wrote: 
> > 3. Add some API to allow plugins to register new sources and a calendar
> > component init hook. The goal of this is to allow plugins to detect the
> > absence of and register new top-level sources, similar to the existing
> > migration code. This will make it so new calendar backends can be
> > distributed completely independent of evolution.
> I don't understand why you need this at all?
> 
> Doesn't the e-source-list manage all of these?  You should just be
> adding a new source the same way other sources are added, and they'll
> just 'work', wont they?
> 
> Once you add the stuff to the new-calendar thing to select the type of
> calendar, the rest should just follow. 

Well, we are in the process of releasing an "out-of-tree" plugin for
integrating OBM http://obm.aliacom.fr with evolution. OBM provides
contact and calendaring. The code register this kind of connector looks
like massive hacks :
 - we created a camel provider and an empty store to appear in the
"server type" combo box in the new mail account wizard, but OBM has
nothing to do with email. 
 - we use the provider to setup a listener on the e-account list, and we
register 2 ebook-sources, and one calendar source for each OBM user that
has a public calendar; This means lots of dirty hacks on the source uri
strings and properties
 - we manually set the e-password for each source we create, because we
didn't found a way to properly inherit the one from the account

For me it seems like lots of hacks, but it works (tm). Screenshot here :
http://dbmjui.sourceforge.net/obm_calendars.png

First release (with both server and connector under GPL) expected soon.

Regards,
Thomas.