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
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution
