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

[Jules Colding <colding omesc com>]

Hi Michael,

On Thu, 2005-08-04 at 11:25 +0800, Not Zed wrote:
> 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.

I know the feeling... 

A high-level "How to get starting coding in Evolution" would be of much
value to newcomers like myself, so any effort spent on such a document
would be much appreciated.


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

Hmm... I need 6 strings and two port numbers besides the host and
username strings. No problem stuffing them into the resource url, but I
am concerned about how the user is going to do the input.


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

At first sight it seems that I need a separate page in the druid to
handle the additional resource data. It sounds like an e-plugin could be
the answer. Are there any sample that shows how to put new pages into
the druid?


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

All of my code is corba anyway, so using corba is definitely a
comfortable thought. I would only need to make all backends access the
same remote corba object using a shared IOR. No problem there.

I already have a fairly complete sample app working with ORBit2 2.12.2
or never (CVS HEAD preferred) and libIDL 0.8.5 or never, so I more or
less expect to be able to use big chunks of that code.


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

Having all of the backend code in eds would, out of my limited
experience with evolution code, really clean things up design-wise. I
find it disturbing that I need to put code in evolution *and* eds to be
able to talk to my server. There should really be a central place to all
backends, being it mail, calendar or whatever.


> > > 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 ;-)

;-)


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

Will the disksummary branch consolidate the design of the backends or is
it "only" the disk access methods that are being addressed?


Best regards,
  jules