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

[Not Zed <notzed ximian com>]

Hi again Jules,

> On Tue, 2005-08-02 at 23:53 +0800, Not Zed wrote:
> > There isn't one, and I doubt that 10 steps would cut it, easy or
> > otherwise ...
> 
> I'm sure your right...

I actually wanted to start writing at least a mail backend document as
part of the new architectural work, and may well eventually do it, but
when I went to start it my mind went blank, so i gave up the idea for
the moment.

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

There are two paths for mail; one is for simple parameters which are
placed on the url identifying the resource, and they can be added as
customisation through the camel-provider structure.  I'm not sure if we
want to deprecate this for various reasons though - although it is
simple to use for simple configuration (e.g. most of the stuff on the
'receiving mail options' tab is from this).

The other mechanism is using e-plugins, you can add whatever you want
(even whole new pages to both the druid and/or the editor separately)
based on the backend type.

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

I think as I outlined later is probably the best.  The actual session is
running in eds, but you have a proxy mail object for the mail code to
access mail data.  This is more or less how evolution-exchange does it.
evolution-groupwise basically just opens 2 connections to the disdain of
sysops everywhere.

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

I guess it's up to you.  I would probably go with CORBA, at least, if
there is a possibility you can use the interface more directly.
Basically because:

eds already uses corba, so it would just be another interface, like
EBook or ECal, you could have EMail (even if eds hides these corba
interfaces from you for some reason).

it's not an interface which needs to be dynamic, corba  is fairly light,
nice and fast - and orbit is thread safe to some extent, and not really
that hard to use.  I guess it depends on what you're comfortable with
really, and if it works in the threaded environment.

see the mail-remote plugin, in evolution/plugins/mail-remote for a corba
interface which already accesses mail.  Perhaps it could use a similar
interface for accessing the data (ideally, i'd like to see cal/addr use
a similar interface too, derived from the same base folder object, but i
think that is just wishful thinking).  This was some development work on
evaluating the possibility of moving mail storage into eds - there are
still some performance and architectural issues associated with actually
doing it yet, but it may still happen one day (it also maps more closely
to the disksummary branch work i mention below).  At least I dont see
any extra overheads to approaching it in a similar way.

evolution-exchange uses unix sockets i think, and a simple custom
message passing mechanism using using binary packets, a bit like d-bus,
and perhaps local caches and the like (certain info will always be
locally cached, but message content needn't be).  See
evolution-exchange/camel for the stub proxy objects it uses; they could
probably just be re-used too.

evolution-groupwise doesn't do any proxying, but it uses soap or some
other xmlrpc thing.

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

Ok, just thought i'd better make the point before too much was
discussed, some have got upset by it ;-)

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

Yeah 2.5/2.6 only, not in 2.4.x.  There is over 1MB of diffs sitting on
a branch (disksummary) at the moment, and still more work to do on it.
The api's are sort of both more complex and simpler, with a similar
feel.  e.g. camel-folder removes a lot of methods that could do the same
thing in different ways, but adds others which change how vfolders work
entirely.  The interfaces are more incremental, searches use iterators
for instance, and the folder provides its own vfolder indices - so
database-like backends should map a lot nicer and use less memory; but
will require a lot more work to get up and running than they currently
do.

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

Not much more or less about it unfortunately.  Mail is completely
separate.  Calendar and Addressbook share some stuff, but nothing of
substance, and/or what they do isn't very good, e.g. ESource, or the
hard to implement asynchronous interfaces (which are then hidden in
synchronous gobject interfaces just to make things messier).

 Michael