Re: [Evolution-hackers] Overview of camel-lite

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2007-06-11 at 14:48 +0530, Srinivasa Ragavan wrote:
> On Mon, 2007-06-11 at 10:57 +0300, Philip Van Hoof wrote:
> > I'm going to make an overview of camel-lite so that if people read the
> > discussions here, that they know what it's all about.
> > 
> > Camel-lite is the fork of Camel that Tinymail is using internally right
> > now. Camel-lite's code is in my opinion not really in a good shape, it
> > more or less implements certain features that are necessary for
> > Tinymail.
> > 
> > Bad things:
> > 
> >  * Some of the features have been done in a hackish way. 
> > 
> >  * Mostly this had to do with non-blocked reads not being very well
> >    supported within the code and design of upstream camel
> > 
> >  * Removes support for a few for Evolution very important but for
> >    Tinymail unused features
> > 
> >  * It's a fork (effectively, yes)
> > 
> > Neutral:
> > 
> >  * I am trying to get some of the changes in upstream Camel. Although
> >    I'm selective because I don't want to bore the Evolution team with
> >    features that they'll most likely not consider for inclusion anyway.
> > 
> >    My point of view is that if they show interested, I'll bump the
> >    priority of trying to clean it up and getting it upstream
> 
> Of course, we are open for patches that are clean and doesn't break
> existing functionality.
> 
> Im fine to push some of your IMAP features from camel-lite, provided
> that there is a safe fallback for servers which do not implement them
> and I don't really want Evolution to break badly for those servers.

All those features are already checked for in the CAPABILITY flags. 

There is one bandwidth improvement in camel-lite that might not work
with some servers: Upstream camel uses "UID FETCH" to get a list of
UIDs. Camel-lite uses "UID SEARCH" for this. Although I will most likely
implement a fall back situation based on the EXISTS count, it might not
be as-nice on a server that incorrectly implements "UID
SEARCH" (although they fixed it, Citadel's IMAP server didn't give a
correct answer to "UID SEARCH").

Important note about the current Camel code, because you just said that
this IMAP code works well with all IMAP servers :-) : According to the
RFC of IMAP, you MUST disregard the CAPABILITY flags after entering
STARTTLS *and* after any change in authentication.

Starting TLS can (and on some servers, like exchange's IMAP, can) change
the capabilities. Authentication can also influence these capabilities.

Upstream Camel's IMAP code does not discard the capabilities at all
required times. It doesn't surprise me a lot that there are so few bug
reports about this, because the majority of 'new features' that you'll
get after either STARTTLS or authentication, only improve the
possibilities of an IMAP server.

For example IDLE on Exchange IMAP servers, will only be in the
CAPABILITY line after authentication (at least some Exchange servers).

ps. Note that this is indeed one of my patches that I've sent in the
past to the patches mailing list (I think there's a bug for it too).

> I think the biggest thing with the current IMAP implementation is that it
> has become stable over a period of time and works fine with most of the
> existing servers and falls back to alternative pat(c)h in case of any
> server issues. I think we need to carry this. 
> 
> I would appreciate you for the things you have done in camel-lite and
> nice to see things going in a constructive way :)

I think (opinion) that the most easy way to get things in a clean way
into an upstream version, is to split Camel away from EDS. I noticed
that Jeffrey wouldn't object and that Matthew more or less agrees with
this point of view (although, don't let me speak for them).

>From that point, I can more easily move functionality from camel-lite
into this camel project (that might have several different types of
versions and implementations).

For me it's important to have a small dependency: I see no reason to
depend on the entire EDS suite, just for Camel (which is a component
that is technically 100% disconnected from all the rest of EDS anyway).

Also important is that the Evolution team can then watch the changes
into this Camel version mature, and Evolution can then use an older
version of Camel (so that things get tested in projects like Tinymail).

It will take a lot of time to expell camel-lite out of Tinymail: I had
to change some types and structures that would have very few to do with
how Evolution works and that would, to correct them in a clean way,
influence the API, ABI and design of upstream Camel a little bit.


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog