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

[Jules Colding <colding omesc com>]

Hi Michael,

Thanks a lot for the info below. Much appreciated :-)

On Tue, 2005-08-02 at 23:53 +0800, Not Zed wrote:
> 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'm sure your right...

My server would require additional information to what is presently
available in the Mail Configuration Assistant. How is the stance about
adding new fields that would show itself when the correct account type
is chosen?


> > 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.

What is the preferred/best way of handling a "global" session object
which is accessed from all components?


> 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.

OK, that sounds like something to do right away as an initial release to
give people a fair chance of giving feedback on the
implementation/design.


> Since you want to have presumably a single session accessing the remote
> resource, 

Yes. Multiple simultaneous session objects accessing the same resource
is no problem as such, but would be a poor design that I would rather
avoid if possible.

> you would probably write in effect a set of proxy objects
> which talked to the actual session object.  

Which mechanism is preferred? CORBA, some IPC method, IP or something
entirely different?


> 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.

Sure, all of my code will be GPLv2 or later.

> 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.

But only in the 2.5 time frame I assume?

> 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.

It more or less sounds like the different backend systems (mail,
calendar, notes etc) are rather independently designed?

Thanks,
  jules