Subject: [lemonade] QRESYNC, I'd like to do a proof of concept

From: Philip Van Hoof <[email-masked]>
Date: Fri, 25 May 2007 13:15:45 +0200

Although busy with a lot of things, I'm very interested in implementing
full support for QRESYNC in Tinymail.

I'm looking for server developers to get it implemented in their server,
so that we can make it work at both sides. Perhaps for now as some sort
of proof of concept? For seeing where the difficulties are.

CONDSTORE introduces quite a lot of difficulties for knowing whether or
not expunges have happened. I think we should avoid this in future.

That "VANISHED" line might actually solve a lot of these problems, but I
can really only know .. more (as testing equals "knowing more") once I
have a working QRESYNC enabled SELECT.

Who's with me? Cyrus? Mbox? Dovecot? Courier perhaps? Oryx? 

I mean, let's just do it. Right?

-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "DINH Viêt Hoà" <[email-masked]>
Date: Fri, 25 May 2007 13:27:39 +0200

> not expunges have happened. I think we should avoid this in future.

Could you describe the problem between EXPUNGE and CONDSTORE ?

-- 
DINH Viêt Hoà

---

From: Philip Van Hoof <[email-masked]>
Date: Fri, 25 May 2007 13:50:29 +0200

> Could you describe the problem between EXPUNGE and CONDSTORE ?

Well, if using CONDSTORE with the sequences, it's only save to use this
if no expunges have happened. Else I might be flipping flags of locally
cached messages that are not the ones that the query's result set
intends. Having to use the uids means a hash-table lookup (which is not
always interesting for a lot of messages on a mobile device).

I'm right now asking for the UID and comparing it (the message that is
to be updated) against that too, and falling back to old synchronisation
code if one message is not in sync.

I also added quite a lot of checks to 'guess' whether an expunge might
have happened, before doing the UID FETCH 1:* (FLAGS) (CHANGEDSINCE
12345) query. None of that checking is really atomic, it's sub optimal
and it's a lot of code that can go wrong in my opinion.

With QRESYNC I would atomically know about the expunges. So I could
update my local sequence table and be sure that both remotely and
locally the syncing would be correct.

-- People don't like it when a message gets wrongly flagged as removed,
so it's not that I can take any risks here --

---

From: "DINH Viêt Hoà" <[email-masked]>
Date: Fri, 25 May 2007 14:02:25 +0200

> code if one message is not in sync.

maybe a simple heuristic for this is to store what the flags looked
like on server when you stored that local flags.
And when synchronizing local changes to the server, first get the
flags of the messages you are going to modify from the server and if
this match what you expected, change the flags on the server to the
value you have locally. And if it does not match, don't apply flags.
I think that will fit most cases.

-- 
DINH Viêt Hoà

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 May 2007 14:51:33 +0100

>always interesting for a lot of messages on a mobile device).  
If your client is using FETCH (as opposed to UID FETCH), an IMAP server 
is not allowed to send any EXPUNGE responses while processing it.

>code if one message is not in sync.
This is a good coding practice anyway.