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 _______________________________________________ evolution-hackers maillist - evolution-hackers@lists.ximian.com http://lists.ximian.com/mailman/listinfo/evolution-hackers