Re: [Evolution-hackers] kolab2 evolution plugin

[Jeffrey Stedfast <fejj ximian com>]

I'm pretty sure he's going to have to implement his own IMAP backend for
Evolution-Data-Server - since EDS runs as a daemon process that other
apps are supposed to be able to query, it probably can't depend on the
main Evolution process running (which is where the camel session would
be).

Altho... I suppose that since the camel libs now exist in the EDS source
tree, he could write an EDS backend that used the camel libs and created
its own mail session to connect to the imap server(s).

Jeff

On Thu, 2004-12-09 at 21:43, Not Zed wrote:
> On Thu, 2004-12-09 at 12:38 +0100, Sebastien Estienne wrote: 
> > Hello,
> > I'd like to start working on a kolab2 connector for evolution, and i'd
> > like to have opinions of evolution hackers on the doability of the
> > project. I asked the question to kolab2 (proko2) developpers, his
> > answer is following
> > 
> > To give a short overview: of how kolab2 works:
> > -everything is stored in imap4 folders (mail/calendars/contact/notest)
> > -an xml format define these different elements in the a mail (rfc 822)
> I presume this stuff is stored in mime or using mime/types rather than
> merely an xml blob in the mails themselves. 
> > -imap folder use ANNOTATE to define there content.
> I guess anything is doable.  It doesn't seem undoable, so long as you
> implment the abstract the api's appropriately.  One issue may be that
> evolution mail is difficult and does things differently to the other
> backends, so it may be an issue with needing to open multiple
> connections to the imap server, or somehow routing requests between
> the various components to the same connection.
> 
> You may, or may not, be able to use the existing imap implementation
> directly for the storage mechanism, which could save you a lot of the
> work.  We don't implement any annotate stuff but there are mechanisms
> to add things like that without breaking the apis.
> 
> We use all of the internet standards for storage, so assuming this xml
> format can be converted to those without loss, it should be no
> problem.  i.e. we use rfc822/rfc204x mime for email.  we use rfc2445
> for iCalendar for calendaring and tasks, and vCard for addresses. 
> Although some of it is abstracted, I'm pretty sure most api's also
> expose this fact as well.  i.e. iCalendar components are passed around
> from backend to client code.
> 
> -- 
> 
> Michael Zucchi <notzed ximian com>
> "Ride, Work, Sleep. Beer."
> Novell's Evolution and Free
> Software Developer