Re: [Evolution-hackers] camel & imap & multiple servers
- From: Not Zed <notzed ximian com>
- To: Stephen Farrell <sfarrell almaden ibm com>
- Cc: evolution-hackers lists ximian com
- Subject: Re: [Evolution-hackers] camel & imap & multiple servers
- Date: 10 Feb 2003 11:21:58 +1030
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
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
> 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.
] [Thread Prev