Re: [Evolution] IMAP rewrite



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.
fejj ximian com  - www.ximian.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]