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

[Not Zed <notzed ximian com>]

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