On Tue, 2006-10-17 at 12:33 +0200, Jules Colding wrote: > > Could Brutus be used for accessing Exchange services using just Camel?
> Yes, I would think so. Something like this has been done before using > the calendar parts of e-d-s: > http://www.omesc.com/modules/news/article.php?storyid=35 Great. > > I'm interested in extracting the Camel-only parts of a Camel provider > > for distribution in tinymail (which is LGPL). > > OK, just bear in mind that Brutus is GPL. Is that a big problem for an LGPL library? I could keep that part of the library GPL, right? Maybe I could patch a version of Brutus in such a way that making a package that will work with tinymail is easy. Etc etc. Probably things that we can discuss about sooner or later? :) > > I understand others are probably also interested in the Exchange > > calendaring and contact pieces and features, but initially I'm not > > interested in any such code or API. > > e-b can currently do mail, calendaring and tasks. More features are in > the works. I will only need the mail part. Which basically means having a CamelFolder and a CamelFolderSummary implementation. > > I was planning to take a look at evolution-exchange(/camel) but if > > Brutus is a better solution (if you can convince me), I'm not afraid of > > picking that. > > I don't know if I can convince you but I'll try ;-) > > e-e is based upon WebDAV while e-b is based upon Extended MAPI. > > I must first say that I've never used the original e-e connector so > everything that I say about it should be taken with a big grain of salt. > > Anyway, I've been *told* that e-b parforms much better and is more > stable. It is also a lot easier to develop with e-b as the Brutus API is > very close to MAPI as documented on MSDN. You should therefore expect > e-b to be easier to maintain and extend than e-e. > > Note that a requirement is that it has to compile and work on multiple > > architectures. Including ARM. > > I've tested e-b on i386 and amd64. I expect it to build and run on any > architecture with a reasonable GNU tool chain. That's the good news. > > It's memory consumption shouldn't be > > extremely bad (if it reuses the CamelFolderSummary pieces, the mmap > > technique can probably be adapted in the Brutus Camel implementation, > > just like what I did for the other Camel providers a few weeks ago). > > > > I have already completed this little-patch for evolution-exchange. I > > haven't yet tested it. > > A patch is always welcome :-) Right but that patch would also make Brutus incompatible with the normal Camel as shipped by Novell ;-). It would basically change the Brutus-specific summary code to in stead of reading from a file using fread, use mmap and point to that. It's a small but required patch for it to work with the mmap stuff. Also note that the summary file format is changed (to be data aligned and padded on 4 bytes, for example ARM requires this when using mmap). > > Support for Exchange isn't a top priority, but its most certainly a nice > > to have feature to bring to mobile devices and embedded appliances > > (which is the focus group of tinymail at this moment). > > > > Let me know what you think? > > I'll help you as much as possible should you decide to take a closer > look at e-b. Just yell or ask and I'll do my best. Great and good to know. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be blog: http://pvanhoof.be/blog _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
