> PvH,
>
> I am really worried about introducing this new concept of "attribute
> directory" and new syntax. Maybe I am just missing the point (in which
> case please explain), but is there anything you can do with this that
> there is no way you could do without it.
> Hans' favourite topic (quite rightly) is namespace unification, which
> involves keeping the syntax as simple as possible, having only one type
> of expression for one kind of logical structure. If you could possibly
> do this without the "..@", do it without it.
>
> So why not just do (to take your example):
>
> $ echo "Matmos" >> track01.mp3/artist
>
>
> Peter F
This is not new syntax, it is a new type of File (well, tecnically, it would
be implemented as a new pseudoplugin.)
From a user's point of view, these files are equivalent to an XML attribute,
whereas normal files are child elements. The semantic difference is, I
contend, significant.
From an implementation point of view, this would allow us to provide guidance
to, or eventually even full FS-level support for indexed attributes.
These attribute directories, like "...." would also be available for
directories, not just files.
Also, important to me is that they could provide Reiser4 xattr compatibility.
(The xattr('artist') for a file would be file/@/artist.)
Personally, I think "..@" is a keyboard-full. I would prefer "@" for improved
consistency with xpath, but worrying about the actual string to access with
is worrying about what colour the shed will be before you put it up.
I think resource directories in the style of OSX have a seperate value to them
and also deserve implementation, but are another (related) project.
Dinner beckons,
-pvh
--
Peter van Hardenberg ([EMAIL PROTECTED])
Victoria, BC, Canada
