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 am about to do just that to current cvs HEAD, but I would be really > grateful if someone, who has done this before, could help me get started > in the right direction. I can imagine that it would take me a lot of > effort to get started on my own. > > What should I look for, are there any pitfalls or experiences that you > would like to share? Hopefully some of the other guys will pipe in here who have done it. I worked on the mail backends only, but since I wrote a plenty of it and have worked on the rest of it, i come from a different angle. > 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. 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. Since you want to have presumably a single session accessing the remote resource, you would probably write in effect a set of proxy objects which talked to the actual session object. 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. 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. 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. Michael _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
