Re: [Evolution-hackers] camel & imap & multiple servers

[Jeffrey Stedfast <fejj ximian com>]

On Sun, 2003-02-09 at 20:34, Stephen Farrell wrote:
> Hmm...  that's too bad because evolution is really important for the 
> acceptance of Linux in corporate contexts...
> 
> Another naive question: can ximian borrow ideas/implementation from 
> mozilla's imap client?  I know that mozilla tends toward the baroque 
> design, but as far as imap performance and reliability goes, they seemed 
> to have really nailed it.  Is it conceivable to put something like xpcom 
> into evolution so it can borrow bits from mozilla?  Or is this all just 
> a much bigger can of worms?

I don't think camel could even use xpcom even assuming that we would
even consider the idea. camel has to remain threadsafe and if xpcom is
even close to bonobo, it's not going to be thread-safe.

it would also be a huge gross hack of a solution.

we already have some code towards the imap rewrite that notzed and I
have each done in our spare time. there is also a recent volunteer
currently starting with the design/impl that I had started working on
the rewrite, although as notzed said - we won't actually be able to get
it in anytime before 1.5.x at the earliest as we are in feature freeze.

You are free to find and assist the other volunteer if you like. I'm
sure he wouldn't mind the extra help?

note that even if the volunteer doesn't even get to it (or get far),
Ximian will eventually push notzed and I to rewrite it - ie, it *is* on
the TODO list. I don't recall which release it is targetted for though
(I believe it is either 1.6 or the release afterwards).

Jeff

> 
> Not Zed wrote:
> > Should the subject read "multiple clients"?
> > 
> > On Sat, 2003-02-08 at 12:02, Stephen Farrell wrote:
> > 
> >>I'm getting a lot of dialogue boxes about "server unexpectedly
> >>disconnected" when running evolution with imap message store.  This
> >>seems to happen when another imap client connects and causes the server
> >>to drop the connection.  I think I have about 4 different computers that
> >>might be connecting to the same imap store.  Evolution needs to handle
> >>this (normal) situation gracefully.  Mozilla does and has for a long
> >>time.
> >>
> >>I took a look at the code and see that it throws up an exception instead
> >>of trying to reconnect.  I also see that somone is really unhappy with
> >>the state of camel_imap_store_readline wrt this issue.  Can someone get
> >>me up-to-speed on the thinking behind this (e.g., it's fixed in the new
> >>release, we have no idea how to fix this, etc)?  I'd be happy to spend
> > 
> > 
> > We have the notion, if no concrete plans, to rewrite imap.  Someone on
> > the evolution list wanted to look at this, I've forgotten to forward the
> > code I was working on so far though, oops.  This is 1.5.x material at
> > the earliest anyway, although it can almost be completely parallelised
> > to other evolution development and be installed backwards ontop of
> > existing setups.
> > 
> > The main problem in the current code is probably the abstraction layers,
> > maintaining internal state, and the convoluted (dis)connection
> > mechanism.  It's kind of hard to reset enough state and re-initiate a
> > connection without causing other problems, like recursion or deadlocks. 
> > The 1.2.x code is probably better in this regard than 1.0.x, although
> > not terribly so.  We've basically put it in the 'too hard' basket
> > because of the limited life expectancy of the code, the poor quality of
> > the code, and the fact it's _mostly_ just an annoyance rather than the
> > end of the world.
> > 
> > It might not *actually* be that hard, as generally when we get a failure
> > we force a disconnect at a higher spot anyway.  Although you would need
> > to retrigger things like SELECT's to restore the state, which could
> > trigger further reconnects or processing, so it could get tricky.
> > 
> > The rewrite will probably be based on an iterative state engine rather
> > than a "programmed recursive mess", so would probably be easier to make
> > work properly.
> > 
> > 
> >>some time fixing this problem as I would really like to use evolution
> >>over mozilla b/c of the calendering capability.  I'm also interested in
> >>general why imap is so much slower with evo than with mozilla,
> >>especially when checking for new mail.
> > 
> > 
> > That kind of depends on the version, 1.0.x did some caching which just
> > impacted heavily on performance.  It also depends on if you're doing
> > filters or vfolders or not, and a bit on the server too.
> > 
> > But yeah I agree, if i was to use one word to describe the code, it
> > wouldn't be printable in polite company.
> > 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com