Re: [Evolution-hackers] Adding a new server type... How?

[Not Zed <notzed ximian com>]

Hi Jules,

> I have been looking at the various documentation in the source and on
> go-evolution.org, but I simply can not find the "How to add a new server
> type in 10 easy steps" document :-)

There isn't one, and I doubt that 10 steps would cut it, easy or
otherwise ...

> I am about to do just that to current cvs HEAD, but I would be really
> grateful if someone, who has done this before, could help me get started
> in the right direction. I can imagine that it would take me a lot of
> effort to get started on my own.
> 
> What should I look for, are there any pitfalls or experiences that you
> would like to share?

Hopefully some of the other guys will pipe in here who have done it.  I
worked on the mail backends only, but since I wrote a plenty of it and
have worked on the rest of it, i come from a different angle.

> The server type in question is session oriented and able to do
> calendaring, addressbook, mail, notes, task and so on, so I would really
> appreciate any help getting started. 

Well, currently one issue is that mail and
calendar/addressbook/task/notes sessions are run in separate processes.
This is not to say you can't access the one session from the other - and
infact you should do this.

But basically there are 3 main areas you have to implement/

Mail, is done using libcamel and libcamel-provider.  You need to
implement a new provider, which will execute in the address space of the
mail application.  A 'provider' is just a loadable module which
implements a CamelStore object, CamelFolder object, and potentially a
CamelTransport (for sending mail) object, and override some virtual
methods.  And maybe some other housekeeping objects.  Depending on the
backend, this isn't a gigantic amount of work - and can be done in
stages, but it also depends on how well the abstraction matches the
camel one.  Which is roughly similar to JavaMail, but a bit different.
e.g. you can write a skeleton store which only lists 'inbox', and
doesn't implement any folder operations, and a skeleton folder which
only implements getting the list of messages and retrieving a single
message and doesn't implement storing changed state or appending.

Since you want to have presumably a single session accessing the remote
resource, you would probably write in effect a set of proxy objects
which talked to the actual session object.  Camel is for the most part
thread-aware/safe, and you can't use gobjects from it, etc (don't look
at the groupwise provider which flaunts all of these rules, to its
potential peril).  The interfaces are all synchronous though, so it is
relatively simple.  The documentation is only really the source-code,
but there are plenty of working (and non-working) examples to look at,
some of which are cleaner than others.  They live in
evolution-data-server/camel/providers/*.  Camel is GPL, so all backends
must be GPL too.

There may be a potentially significant architectural change in the above
camel objects after 2.4; but i'm not sure yet.  That may be something to
keep in mind.

Calendar (also used for tasks and notes) and Addressbook each use their
own backend system.  I think you can do it by implementing a CORBA
interface, or perhaps it has some other layers on top so you implement
sets of gobject based interfaces.  It has some strange in-built
asynchronicity in the interfaces too (I didn't write it, but it looks
strange to me).  I think it has some pluggable backend mechanism - but
if you use CORBA you just register a new server anyway, so it can always
use that.  I don't really know much about these though, mail is really
it for me.

 Michael