Re: why not use IMAP FLAGS?

[martin f krafft <madduck@xxxxxxxxxxx>]

also sprach Jan Hudec <bulb@xxxxxx> [2007.09.02.1453 +0200]:
> author and date -- and the other pertains to relation of user to the document
> -- folder it is in, whether it was read, replied, needs attention, for
> documents the filename etc.
> 
> And the question is, which kind are the tags we want to design?
For me, it's "the other": tags relate a mail to other processes in
my life.

> But if tags are user-relation attributes -- and I am inclined to
> think they are, because they are generalization of folders --
> storing them in headers feels wrong.
> 
> One way to decide the question above is: If I forward a message to
> somebody else, should the tags go along? I believe they should
> not, which is why they should not be headers, because those would.

Good point. This could be solved by using namespaces such that your
tags could never conflict with mine, but on the other hand you may
not want me to know what you tag your mail as. Then again, my mutt
does not forward headers other than the ones I tell it to.

Tags are metadata "about" mail messages as wholes, each mail being
an object that you should not really have to look into. Thus,
metadata should be stored separately. But with offline
synchronisation in mind, this means that we need to find a way to
transport such information via IMAP, which does not seem fit for the
task right now, at all.

And getting IMAP to cater for those needs is going to take a decade,
and even then not everyone will support all extensions. See below.

> I believe it is not possible, simply because noone thought about
> such use when they designed IMAP. We can propose an extension to
> IMAP once we have a good solution for actually storing the flags
> in maildir, which is the bigger problem.

Storing them in filenames might be possible. Offlineimap already
stores metadata in those, but storing utf-7-encoded tags in there
might just make file names grow too long.

> > Note how the flag stays on the folder even after expunging the
> > message: http://dovecot.org/list/dovecot/2007-August/024988.html
> 
> We could probably propose an IMAP extension to remove a keyword.
> I initially thought the extension should simply be to make flags
> starting with eg. : to automatically go away when they are no
> longer used, but than I realized the user interface might want to
> show the user list of all keywords he defined, even if they are
> not in use at the moment, so it'd be probably better to define
> extension command to explicitely remove a flag keyword.

Sure. However, rather than proposing an extension, I'd suggest
getting the dovecot, courier, and offlineimap, possibly even
evolution and thunderbird people interested and then start to
implement stuff. Standards are lovely, but I prefer them to document
existing practice since that also puts a cap on endless discussions
with which many RFCs have been tainted.

> I am inclined to think that this is the case where extended
> attributes are the right tool for the job (while I think they are
> not the right tool for many uses they have been proposed for so
> far, like the mime-type). It's kind of generalized filenames, so
> they should be handled similarly. It also extends well for other
> kinds of documents, so it can be grown to general tool somewhat
> along the lines of the namesys future vision, possibly even with
> some kernel support.

The problem I see with extended attributes is that the standard
tools like tar, cp, rsync, scp etc. don't deal with them at all, and
nor will ls and other Unix goodies. Undoubtedly, this needs
changing, but my not-so-recent attempt to get scp to support copying
of ACLs lowered my hopes and expectations that this will happen in
time before I say bye to computers and submit myself to a bhuddist
monastery.

> There are two ways to store the flags in the filesystem. Either
> a single extended attribute (user.tags), with value containing the
> whole tag list, or a separate extended attribute (user.tag.<name>)
> for each tag, usually with empty value (but we could have valued
> tags too; they could be stored key=value in IMAP and the single
> xattr). The single attribute is slightly easier to read/parse,
> because with multiple tags the other attributes need to be
> filtered out from the listxattr result and possible values need to
> be read separately. On the other hand the separate xattrs are
> better for concurrent access (adding/removing tags needs locking
> in the single xattr case) and lends itself better to future
> in-kernel optimization, because there can be useful index, which
> can't be said for the list-valued single xattr.

in terms of synchronisation, we might also need to timestamp each
tag's addition or removal.

> Unfortunately not all filesystems support extended attributes yet.

I'd say that's tough for them. If FooFS still doesn't support those
standardised attributes, then it's just good that users eventually
stop using FooFS.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
 
"ich bin ein berliner!" (i am a jelly donut)
                                          -- john fitzgerald kennedy
 
spamtraps: madduck.bogus@xxxxxxxxxxx

-- Attached file included as plaintext by Ecartis --
-- File: digital_signature_gpg.asc
-- Desc: Digital signature (see http://martin-krafft.net/gpg/)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG3WYyIgvIgzMMSnURAu7hAKC/kkHBoecEl4LNauqM4nAIN7yKcgCfXv6d
Yb/5QMe4e72gwTqTEGceilk=
=YrJX
-----END PGP SIGNATURE-----