Serialize extended attributes ?

[Joe Mason]

On 7/16/07, Vegard Nossum <vegard at peltkore.net> wrote:
>
> > This problem occurs also when you want to send a file to someone else
> > or when you want to store a document with extended attributes on a
> > filesystem where extended attributes are not available. So what about
> > creating a special file that will serialize extended attributes. So the
> > data found in these attributes would not be lost.
>
> This is very possible. This automatically solves a lot of problems, also
> for instance that of losing metadata when you download a file over HTTP.
> (Just download both the file and its .metadata and nothing is lost; heck,
> Apache could be modified to serve these files virtually even if the file
> on the server has metadata stored using real fs xattrs).


...

It would be nice to have a format specification for the serialized xattrs.
> However, this is not enough. There must also be a C library that
> implements the specification. If not, the file will never be used
> consistently. I think such a library should easily provide transparent
> access to native filesystem xattrs and serialized metadata file with as
> little user interaction as possible (ie. simple from user/developer point
> of view).
>

There's also the question of what exactly gets stored in the xattr's.  Just
the MIME type?

This seems like a good time to jump in and make the suggestion I signed up
to the freedesktop lists for - is there any interest in cloning Apple's UTI
(Universal Type Identifier) metadata system?  It defines a heirarchical
standard of file types, with rules on how each "legacy" type source (on Mac,
that's file extension, MIME type and the old pre-OSX "creator codes") maps
to a UTI id.

It has several benefits over MIME types:

- It's heirarchical, so any app that registers as being able to handle
"plain text" also automatically gets registered to handle XML (and any
dialect of XML), source code, etc.  (With MIME types or file extensions, you
have to add specific rules to know that, for example, text/vxml is a subtype
of text/xml - there are only 2 levels in the heirarchy.)
- It uses reverse-DNS format for namespacing, whereas the only namespacing
MIME types have is the "x-" prefix for non-standard types, which still leads
to namespace conflicts if different organizations want to define similar but
not identical types.  With UTI's we could define standard types as "
org.freedesktop.SomeNewType", and if individual desktop projects or apps
want to jump ahead and define their own without waiting for freedesktop
consensus, they'd use "org.kde.*" or "org.gnome.*"
- On Macs, there's the advantage that UTI info is stored in the filesystem
using extended attributes, so there's always a UTI identifier associated
with each file.  If it didn't originate on a Mac, the UTI can be inferred
from file extension, MIME type if available, or whatever.  (I'm not sure if
the Mac uses magic numbers or just ignores them, but if we clone them we'd
certainly want to include libmagic as a source of "legacy" type info.)

I'd recommend looking at the way the Mac stores its extended attributes on
non-HFS+ volumes (I believe it uses a hidden ".DS_Info" directory).  If the
format is simple enough, we might be able to clone it exactly, thus allowing
Mac's to make use of our metadata  and vice versa automatically.  I also
think that implementing an open-source UTI library would be a fun project
that would provide a lot of benefits for any desktop that wants to use it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070716/608b53d1/attachment-0001.htm