syncing custom IMAP flags

[Nicolas Sebrecht]

On Sat, Dec 04, 2010 at 08:28:44PM -0500, Dan Christensen wrote:
> Nicolas Sebrecht <nicolas.s-dev at laposte.net> writes:

> 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.

Ok.

> 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.

Why not.

> 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.

I still have no idea what sides effects we could have with such change.
This looks pretty sensible at a first glance but I need more than
discussions.

> 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.

Could you please send the patch inlined?

-- 
Nicolas Sebrecht