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 - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
