Re: [Evolution-hackers] OWA with "SessionGuard" [OT]

[Philip Van Hoof <spam pvanhoof be>]

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