Forgot to mention that we ar in feature freeze for 1.4, so this can't go in until at the earliest 1.6 assuming you implement it.
secondly, we are going to need you to assign copyright of any code you write to us. (meant to mention these in my previous email but forgot) Jeff On Wed, 2003-01-29 at 11:45, Jeffrey Stedfast wrote: > On Tue, 2003-01-28 at 00:43, Timo Sirainen wrote: > > I remember reading something of IMAP rewrite, how far did that get? > > not very far > > > Is > > there still a chance of getting that soon? > > Well, it won't make it into 1.4 but it might make it into the following > release. Depending on time... > > > > > I'm thinking of fixing the IMAP code myself soon, unless there's some > > larger changes coming out soon. Was there some plans to change the Camel > > API? > > the only API changes that we have planned are for allowing multiple > namespaces. > > > I remember reading something about it.. Anyway, what I want fixed: > > > > - Currently it's just "write command", "wait for reply". It should > > rather be waiting for IMAP replies all the time. > > afaik, IMAP cannot send untagged responses "whenever it wants to". It > may only send them as part of a response to a command. > > if you can point me to the location in rfc2060 that says otherwise, > please do so. > > > Server can send them at > > any point, Evolution actually breaks currently if that's done before > > APPEND. > > oh? > > > I want to use my server's ability to notify of new mails > > _immediately_ after they come to selected mailbox. > > I presume you are talking about that fam-like extension? > > > > > - Send the flag changes to the server immediately. > > the problem here is that camel_folder_set_message_flags() doesn't take > an exception argument (ie, it is not allowed to fail - thus it *cannot* > talk to the server). > > > I think it now waits > > until closing the folder. > > actually, it waits until any point at which it syncs with the server. > This includes the following situations: > > 1) change folder > 2) expunge > 3) NOOP timeout (if there are flags to sync, it will sync them rather > than doing a NOOP) > > > Also keep the flags synced with the server all > > the time, if I change them elsewhere I expect Evolution to update them > > internally as well. > > yes, this would be nice... > > to do this right, what we'll need to do is store a copy of what the > server's flags are for the message and a copy of what the current state > of the flags are as displayed by evolution. when we are notified by the > server that the flags for that message have changed, we assign that > value to the store_flags and the display_flags *if and only if* the > display_flags are the same as the store_flags (ie, they have not been > changed by the user in this client). > > > > > - Labels should be sent to server using custom message flags, assuming > > the server supports them. > > sure... > > > > > - If IMAP connection hangs to one server, it shouldn't affect the rest > > of them. > > this has nothing to do with the imap code > > > And in general there seems to be several annoying problems when > > one or all connections die, I just can't remember what exactly now. Oh, > > and send NOOP to server once in a while > > we do...? > > > , if it can't get a reply soon, > > reconnect (to work around hanged TCP connections). If server kills the > > connection, silently reconnect instead of complaining. > > we generally try, but the code is a message so not all places that a > disconnect can happen are covered. but yes, this is a must if/when the > imap implementation gets rewritten. > > > So .. Any comments on how easy it would be to fix the problems above? > > not easy at all. > > > I > > haven't studied too deeply Evolution's code yet. The first thing worries > > me a bit as it might require larger changes.. How is the IMAP code run > > now? Is it in it's own thread? > > no > > > Or is it just called whenever something > > is clicked and it blocks while waiting for reply? > > pretty much this is the way it works, although it only "blocks" in > another thread. > > > Could I just register > > the connections fds into GLIB's main loop and make the code asynchronous > > in general? > > no, camel MUST remain threadsafe and well, glib gio-channels aren't. > > I have the start of a CamelImapStream implementation at > http://primates.ximian.com/~fejj/camel-imap-stream.h and > http://primates.ximian.com/~fejj/camel-imap-stream.c > > I was hoping NotZed would reply, he also started working on an > implementation and got much further along than I did. > > new design ideas: > > CamelImapStream: stream class meant to provide useful tokenisation when > reading input. (the current code reads in the entire response and then > parses it in memory - kinda yucky). > > CamelImapEngine: take a look at CamelPop3Engine to get a feel for what > we want this to do. Basically it is what queues CamelImapCommand > structures (or objects?) and sends them o the server when it can. Should > also be responsible for handling "* BYE" and auto-reconnecting? Not sure > about this... > > Now, my idea (and I think NotZed agreed?) was to take CamelImapEngine a > step farther and have CamelImapDriver - a thin abstraction on top of > CamelImapEngine which brokers CamelImapCommands to the best > CamelImapEngine for the job. Basically, it would be responsible for > multiple CamelImapEngines - this would allow us to have multiple > connections tot he server so that we could parallelise some commands. > > CamelImapStore and CamelImapFolder would of course use these engines > and/or drivers just like CamelPop3Store and CamelPop3Folder use > CamelPop3Engine in the pop3 code. > > NotZed has these ideas more polished than I do, since he's the one that > has been playing around with some things. I think he also has an > implementation of CamelImapEngine that works. > > He'll probably respond sometime later (he's asleep now although he does > know about this message, probably just hasn't finished getting his > thoughts together). > > Jeff -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
