Re: [Evolution] IMAP rewrite



On Thu, 2003-01-30 at 22:44, Timo Sirainen wrote:
On Thu, 2003-01-30 at 13:35, Not Zed wrote:
I wrote a ton of code, but didn't quite get to the implementing a folder
stage, close though. 

Can I see it?

I'll try find the latest version (i've got 2 machines), and try package
it up.

One problem is it uses some 'experimental' exception stuff implemented
ontop of longjmp.  Some extra support is required to avoid problems with
it and compilers.

- Send the flag changes to the server immediately. I think it now waits
until closing the folder. 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.

They are two different problems.  Evolution ignores unsolicited FETCH
responses, so flags chagned elsewhere aren't updated.  Updating flags
immediately will need more work than just "updating them immediately",
so that multiple flag changes (which are done one at a time via the api)
aren't done one at a time via the connection (== very slow).

I was thinking the flag changes could be stored somewhere and synced to
server once in a few seconds.

You'd need a management thread or something.  Camel can't use
g_timeout's either.

- Labels should be sent to server using custom message flags, assuming
the server supports them.

This is part of the mailer, not the imap code.  It has to work with all
backends too (which it should already anyway, including IMAP i think).

Looks like it's notified to camel with set/get_message_user_tag("label",
"..."), so it would be possible by mapping that with custom flags for
servers that do support them ("\*" in PERMANENTFLAGS).

I'd also rather not depend on Evolution to keep those flags. They would
be important to me so I'd have to keep backups of ~/evolution too, which
is in different computer than my other mail. Also I might still want to
find messages with those flags when I'm not home (where my Evolution is
running).

I dont know what you're saying here.  If the flags are stored in the
server then they wouldn't depend on evolution.

Currently I'm just leaving messages unseen which I need to deal with
later, labels would be nicer.

It would
probably be easiest to do something like it is now, and maybe add a
thread or something that handles unsolicited incoming data.

Yes, I was thinking of reading and handling the incoming data in
separate thread. Most untagged replies would also be handled
independently on what command (if any) triggered them.

I think the camel-caller thread should just put the command it wants
into some queue and just wait for the connection thread to finish with
it.

Yeah that seems a resonable approach.  We have so far tried to make the
code work without threads also, but i guess there's no real reason to
enforce that capability.

What IMAP server are you using anyway?  The ones I test against are
pretty limited and dont really suffer a lot from evolution's poor IMAP
implementation (e.g. they dont do responses without requests, etc).

My own, http://dovecot.procontrol.fi/

Cool, i'll check it out.

 Z





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