syncing custom IMAP flags

[Dan Christensen]

Nicolas Sebrecht <nicolas.s-dev at laposte.net> writes:

> On Sun, Nov 21, 2010 at 04:36:09PM -0500, Dan Christensen wrote:
> 
>> The more I think about it, that stranger it must seem to the user to add
>> a table like the above when they are syncing IMAP to IMAP, since the
>> single-character flags are just used internally by offlineimap.  So no
>> matter *what* characters are there, as long as they are consistent from
>> run to run and don't overlap standard characters, the sync should work
>> fine.  So why does the user have to specify those characters?
>
> You give the answer if your previous sentence. How could we know if
> extra flags are consistent? Force users to add extra flags themselves is
> a way to prevent from odd breaks and prevent users.

I think it's the opposite.  If the user is free to set the mapping
between custom flags and single characters, they could make it
inconsistent from run to run.  And they have no way of checking the
mapping used before, since it's hidden in the Local Status and only used
internally by offlineimap for IMAP to IMAP syncs.  If instead
offlineimap deals with custom flags, there is no chance it will get
messed up.

Here's my summary of the situation:

1) For IMAP to Maildir syncs, it could be useful for the user to provide
an extension to the default custom flag <--> single character mapping,
since those single characters are stored in the Maildir and therefore
the user cares what they are.

2) For IMAP to IMAP syncs, both ends of the sync store the custom 
flags. The single-character flags are an implementation detail of how
offlineimap treats an IMAP server as some kind of virtual Maildir.
So offlineimap should be able to handle custom flags without any
user customization.  Here are two possible strategies:

2a) The cleanest is if the custom flags are simply stored in full
in the Local Status, with no use of a mapping table at all.  I don't
know how hard it would be to do this.

2b) Less clean, but maybe easier, would be if offlineimap generated a
random single-letter code for each new custom flag it sees.  It would
then need to store this mapping table in or beside the Local Status.

In any case, could the attached clean-up patch be applied now?  It will
certainly be part of any more advanced handling of custom flags, so
if it gets merged now then it won't be lost.

Thanks,

Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: imaputil.py.patch
Type: text/x-diff
Size: 1487 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20101204/35a19706/attachment-0003.patch>