syncing custom IMAP flags
jdc at uwo.ca
Sun Nov 21 21:36:09 GMT 2010
Nicolas Sebrecht <nicolas.s-dev at laposte.net> writes:
> Couldn't it be more user oriented without needs to touch .offlineimap.py
> at all? The main defect I see of the current implementation is that it
> would affect all repositories.
> I was thinking to something like :
> # [Repository Blah]
> # extraflags = [('gnus-expire','E'),
> # ('gnus-dormant', 'Q'),
> # ('gnus-save', 'V'),
> # ('gnus-forward', 'W')]
That looks very sensible.
> On Sat, Nov 20, 2010 at 12:39:29PM -0500, Dan Christensen wrote:
>> Alternatively, could offlineimap handle the IMAP --> IMAP case
>> separately and simply copy the flags as is?
> Why not. I didn't look at the code (and don't know enough myself too) to
> know if it is reliable but I may merge a seperated well-tested patch for
> this case.
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?
I'm guessing those characters are stored in the local cache. If instead
we were simply able to store the full custom flag name, the table
wouldn't be needed. I don't know anything about the format of the local
cache, but if it could be easily extended to handle strings instead of
characters, that would be great. Then the flagsimap2maildir and reverse
functions could be changed so that when a custom flag isn't in the
table, they return it unchanged.
If changing the local storage format would be hard, this could be done
as part of the migration to a database.
Note that it still might make sense to provide the user the ability to
add extra flag mappings like above, for those who are doing imap to
More information about the OfflineIMAP-project