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

[Stephen Farrell <sfarrell almaden ibm com>]

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?

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.