Re: [Evolution-hackers] calendar EPlugin plans
- From: Not Zed <notzed ximian com>
- To: Thomas Cataldo <thomas cataldo aliacom fr>
- Cc: David Trowbridge <David Trowbridge Colorado edu>, evolution-hackers ML <evolution-hackers lists ximian com>
- Subject: Re: [Evolution-hackers] calendar EPlugin plans
- Date: Fri, 15 Oct 2004 17:58:17 +0800
On Fri, 2004-10-15 at 11:17 +0200, Thomas Cataldo wrote:
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.
But this has nothing to do with the source stuff. It is totally not required once you have Davids patch in. It was only a way to gain access to the cpu so you can alter the program behaviour and is not required anymore.
- 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
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.
- 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
Well thats how its done for all the 'native' backends. There is a properly on the source which says it requires a password.
For me it seems like lots of hacks, but it works (tm). Screenshot here :
First release (with both server and connector under GPL) expected soon.
] [Thread Prev