[PATCH] Re: introducing xattrMaildir: a Maildir repository where message files have all IMAP flags in an extended attribute

[Nicolas Sebrecht]

On Tue, Mar 12, 2013 at 08:25:47PM +0100, Erik Quaeghebeur wrote:
> >> First of all, I must stress that this patch cannot work without my
> >> earlier one “Let OfflineIMAP sync all flags between IMAP servers, not
> >> just Maildir-compatible flags”, which is far more invasive, but—I
> >> think—also useful to a much wider audience; formulated differently: I
> >> think it corrects a historically understandable but wrong design choice
> >> and is the more important of the two, needing close scrutiny.
> >
> > Could you elaborate about this "wrong design choice", please? I don't see what
> > you're talking about and how you enhance it.
> 
> Consider a message on IMAP server A with IMAP tags '\\Seen' and 
> 'Custom'. Consider an IMAP server B and a Maildir repository C. Call D 
> OfflineIMAP's internal representation (the 'flags' variable).
> After synchronization of B and C with A, we have:
> 
> * Before my first patch:
> 
> 	A: (\Seen Custom)
> 	B: (\Seen)
> 	C: S
> 	D: \set(['S'])
> 
> * After my first patch:
> 
> 	A: (\Seen Custom)
> 	B: (\Seen Custom)
> 	C: S
> 	D: \set(['\\Seen', 'Custom'])
> 
> * After my second patch, letting C be an xattrMaildir:
> 
> 	A: (\Seen Custom)
> 	B: (\Seen Custom)
> 	C: S (in filename info field)  and
> 	   "\\Seen Custom" (in user.org.offlineimap extended attribute)
> 	D: \set(['\\Seen', 'Custom'])

Ah ok. This was not a wrong internal design choice, BTW. AFAIK, it
always was intended. OfflineIMAP is ought to support maildir without
fancy features. But your patch makes sense for some users, I think.

Now, I'd say that using extended attributes to store custom flags is a
somewhat arbitrary database. Not all filesystems support it. Though, it
has the advantage of not having a database seperated from the mail file.

Thanks.

-- 
Nicolas Sebrecht