[sup-devel] Storing message tags and other Sup info as headers in Maildir

From: Sean Whitton <sean@silentflame.com>
To: sup-devel@rubyforge.org
Subject: [sup-devel] Storing message tags and other Sup info as headers in Maildir
Date: Fri, 4 Jun 2010 14:44:04 +0100	[thread overview]
Message-ID: <20100604134404.GA28767@artemis.silentflame.com> (raw)

[-- Attachment #1.1: Type: text/plain, Size: 1852 bytes --]

Dear all,

I've been checking back to the Sup website every few months for the past 
year or so, waiting until Sup starts to look more stable and suitable 
for regular use.  Like many people on this list, a great stumbling block 
to adoption is the fact that Sup doesn't really let you access your 
e-mail with anything other than Sup.  At the moment I use offlineimap 
and read my mail with Mutt, but my phone and SquirrelMail can access the 
Maildir just as well (by IMAP in the former case), and so everything 
stays in sync and I can get to my e-mail from many places.

Now, I am no real coder, and I've never written a line of ruby, but a 
thought has occurred to me that I feel I should at least share, even if 
it turns out to be completely impractical.  Why not store the 
information associated with e-mails that is not rebuildable (that is, 
tags, unread/read status, starred status, archived/killed/spam status) 
as header lines (X-Sup-Tags: X-Sup-Status, and I guess read/unread could 
be standard Maildir flags) in the e-mails themselves in the Maildir?

This way, the Sup index could be rebuilt on multiple client machines 
without any data actually going out of sync.  You'll still have a 
punishing index rebuild every time you view your mail on a new machine, 
but they'll never be the problem of things actually being wrong - tags 
and stars and the like can all be propagated by offlineimap/IMAP.  The 
indexer can rip out these flags into its index to maintain Sup's 
professed speed, and then if they change, write them back into the 
Maildir along with read/unread status and other flags.

Does this exposition make sense?  Is this a practical way to 
improve/create Sup's multi-client support?

S

-- 
Sean Whitton / <sean@silentflame.com>
OpenPGP KeyID: 0x3B6D411B
http://seanwhitton.com/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel