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

[Not Zed <notzed ximian com>]

On Thu, 2005-08-04 at 10:33 +0200, Jules Colding wrote:
> 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.

Look at the mail account settings for imap.  The 'receiving options
page' on the account editor is all done from the camel-provider option
list.  So the user just enters them as normal widgets ...

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

I dont think you do, receiving options has space for a few strings.

Almost all the plugins currently in existance are in the plugins/
directory, some of them add pages, like the groupwise proxy stuff.


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

Oh good-o, that should help.

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

*shrug*  plenty of reasons it wasn't done that way, and I think they
were fair at the time.

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

It is absolutely nothing to do with anything but mail.