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

Erik Quaeghebeur offlineimap at equaeghe.nospammail.net
Tue Mar 12 20:53:34 UTC 2013


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

Sorry for using that "wrong..." phrase. 't Was not very constructive. 
The design makes perfect sense when doing IMAP <-> Maildir only.

 > But your patch makes sense for some users, I think.

Indeed, since OfflineIMAP gained IMAP <-> IMAP support, the Maildir 
focus lost its justification, and Maildir becomes just one of the sync 
repositories. Also, since the advent of MUA's based on tagging (sup, 
notmuch) or supporting tagging well (Thunderbird) it has become useful 
for users of those MUA's to get access to all IMAP flags (to make them 
into tags _and_ push those back to their online IMAP server, so there is 
no need to SSH to a server with the MUA for remote access), which is the 
reason for my second patch. [The support for notmuch is not here yet...]

 > Now, I'd say that using extended attributes to store custom flags is
 > a somewhat arbitrary database. Not all filesystems support it.

True, but as far as I know, all currently standard Linux (ext3, ext4, 
btrfs) and Mac OS X desktop filesystems do, and NTFS has a similar 
feature, but I think pyxattr does not support that.

 > Though, it has the advantage of not having a database seperated from
 > the mail file.

That is intended: it requires minimal extra logic and in any case, it is 
an intermediate representation before being put in a database that also 
indexes lots more stuff (e.g., message headers) for fast searches.
Furthermore, flags are the kind of thing extended attributes were made 
for: metadata.

But: although I tried to find and deal with all locations in the 
OfflineIMAP code where flags are assumed to be Maildir-ones, I am not 
familiar with the code. I hope the maintainers can fill this gap.


Best,

Erik



More information about the OfflineIMAP-project mailing list