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

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]