Hi again Michael, On Fri, 2005-08-05 at 13:51 +0800, Not Zed wrote: > On Thu, 2005-08-04 at 15:08 +0200, Jules Colding wrote: > > On Thu, 2005-08-04 at 21:02 +0800, Not Zed wrote: > > > > > > Well, personally ... i think it would be better to do it as a completely > > > separate project. > > > > > > A few reasons - it is easier to distribute/manage, and it tests and > > > validates all of the extensibility mechanisms we have put in recently. > > > > Could you give me a few words about which mechanisms, please? > > All the ones you'd need to use anyway ... > > Camel backends are only installable as extensions, for instance. So > there's no choice - it doesn't matter if they're installed separately or > in the main tree.
So I basically just implement a shared camel library for my provider, puts it in "$PREFIX/lib/evolution-data-server-$VERSION/camel-providers/" with an .urls file describing the supported protocol? Will Evolution then automatically discover my camel provider or do I need to tell evo about it in some other way? I am being a bit confused here. I thought that Camel was mail and mail only. The extensions that I am seeing in the eds extensions directory are all addressbook or calender related...? > All calendar backends are abstracted from the frontend already too, so > there isn't really any choice there either, and i believe they can also > be installed separately. I see some e[cal,book]backend shared libraries in "$PREFIX/lib/evolution-data-server-$VERSION/extensions/. Are they automatically registered with Evolution? Should I just put my own one there?? Thanks, jules _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
