On Mon, 2007-06-11 at 12:47 +0300, Philip Van Hoof wrote: > 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). >
Every time we discuss the first road-block is the split. Why don't we do some progressive work together before we discuss on this? It would have made real sense if there are many projects that depends on camel. For now, it is just Evolution and tinymail. I dont see a great point in splitting it. I remember that we had discussed it too many times at various forums. (Guadec/Mail/bugs/...). I'm not in favor of it atm. -Srini. > >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. > > _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
