Re: Two usage examples for attribute directories.

[Hans Reiser <reiser@namesys.com>]

Peter Foldiak wrote:

> Peter van Hardenberg wrote:
>
>>> 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.)
>>   
>
> But why do we need a new type of file? What can you do with it that
> you absolutely couldn't without?
> What is wrong with my simplification of your example?
> (track01.mp3/artist)
>
>> From a user's point of view, these files are equivalent to an XML
>> attribute, whereas normal files are child elements.
>
> I never quite understood the need for XML attributes either. You could
> easily survive without them, right?
>
>>  The semantic difference is, I contend, significant.
>>   
>
> Could you explain this difference.
>
>> From an implementation point of view, this would allow us to provide
>> guidance to, or eventually even full FS-level support for indexed
>> attributes.
>>   
>
> Sorry for my ignorance, what is an "indexed attribute" and what's good
> about it.
> Are you sure the simple "/" is not a more elegant and simple way to do
> all this.    Peter
>
>
I agree with Peter's questions.