On Mon, 2003-02-10 at 12:04, Stephen Farrell wrote: > Hmm... that's too bad because evolution is really important for the > acceptance of Linux in corporate contexts...
Generally corporate contexts only use a single client per user anyway. I dont really see your point anyway; its a known issue. > 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 dont really see this happening, but I guess it could. > 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 - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
