xattrs support and uses

[Gabriel de Perthuis <Gabriel de-Perthuis laPoste net>]

Le mardi 07 juin 2005 �2:28 +0200, Alexander Larsson a �it :
> See my last reply:
> http://mail.gnome.org/archives/nautilus-list/2005-May/msg00123.html
Oh, I did miss that. *sigh*

> I want to wait until there is a clear idea of how/if/when we want to
use xattrs in the desktop.

Therefore I'd like to raise the question:
How can we make extended attributes more useful for the desktop?

I think we already have lots of metadata in diverse places that could be
represented as extended attributes; and also metadata that we don't have
yet but that would be useful.

Xattrs I'd like to have are
  * a source attribute - for browsers to tag the files they download,
  * subject - some keywords about the topic of the file, can be used for
feeds and posts in aggregators, for images and photos, webpages and
e-mails. Evolution, epiphany, straw, gthumb all have support for
categories, so sharing them would be good. Sharing the user's vocabulary
would definitely be a plus.
Since metadata are much, much more useful when they are shared between
applications, good naming and formatting conventions are very important.
source and subject are dublin-core elements which saves some work -
http://dublincore.org/documents/dcmi-terms/ , but conventions for string
encoding (utf-8?), uri representation (url-encoded or not), and more
precise meaning are still necessary. As far as naming, user.dc.source
looks good. The conventions should be documented in a similar way as
shared mime info, by xml files in /usr/share/metadata-info, so that file
managers may give a useful representation of metadata they don't
understand beforehand.

Gnome already writes lots of metadata, here's what I found:
.nautilus/metafiles contains xml files named after encoded urls, that
carry information about window positions of child directories;
.thumbnails contains images named after hashes of the files they
represent; nautilus has emblems, fancy backgrounds and notes - I don't
know where/how they are stored.
Most of these can be stored either as string attributes
(user.application.nautilus.emblem,
user.application.nautilus.window-position ...) or as uri or hash
attributes (thumbnails - storing a hash avoids recalculating it). This
would simplify code, and would make this data more resilient to
cp/mv/(s)tar... operations. We would have to write a vfs api that
fallbacks on some .xattrs folder for filesystems like vfat or ftp before
replacing existing methods however.

The user.mime_type xattr is part of the shared-mime-info spec, but
gnome-vfs doesn't currently use it -
http://standards.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html#id2522796

The arstechnica link has some interesting information about xattrs, but
maybe we want to wait for OS X to do it before copying them ;) The
file-type system in particular looks promising to me.

Back to the property page - Adding support of attributes to applications
doesn't require adding a property page, but since most attributes are
short human-readable strings, why not allow the user to do it. When more
complicated data is used, putting it to a user.data namespace that is
ignored by the property page would do. If you look at the code the
property page already refuses to edit binary data.
When the time comes we could filter out known attribute types - eg
security.selinux.* - and give an alternate presentation of them.

So - what should we begin with? Extend applications, add a gnome-vfs
layer, write a shared-metadata-info spec? And do we want a property
page;)