Plugins: Pseudo-fun.

Plugins: Pseudo-fun.

[Peter van Hardenberg]

Project update:
-------------------
Well, we have wallpapered one of the labs here at UVic with Reiser4 code, 
printing page after page and taping them together, hanging them on the walls 
and highlighting them. This was the first time in years that I missed having 
a dot-matrix tractor-feed printer around. 

Tracing the execution down through the various chains of plugin methods into 
the plugin set and then into pseudo.c. Pseudo.c is a much better example file 
than dirc or file.c, the comments are superior and there are many small 
examples of plugins. Here we had our insights and our inspiration:

Although the overall goal remains elusive, we think we should be able to 
implement a new Reiser4 pseudo directory in 4dot (/..../). This directory, 
called "user" will contain per-file user-defined attributes. These will be 
(if I am using the terminology correctly) grandparent-locality-packed and 
will be, by convention, very small. (Perhaps the user attributes should be 
somewhere else? ...attributes vs ...system? I know this is one of those 
ongoing debates.)

Playing nice with xattr:
----------------------------
It is my opinion that xattr support could be added to provide an alternate 
interface to the same mechanism, thus applications expecting xattr would be 
able to both read and operate on reiser file-style attributes, a major win 
for interoperability. Gotta read more.

Big Question of the Day:
--------------------------
One big question that follows from today's discoveries and plans: What would 
be the best method to store these small attribute files? I see no need to 
reinvent the wheel -- this is a directory -- but how/where do we store the 
data? Suggestions welcome.

Odd Behavior:
------------------

Regression problems immediately spring to mind:
pvh@arroyo:~/reiser/test $ cd ....
pvh@arroyo:~/reiser/test/.... $ cd ....
pvh@arroyo:~/reiser/test/..../.... $ cd ....
pvh@arroyo:~/reiser/test/..../..../.... $ cd ....
pvh@arroyo:~/reiser/test/..../..../..../.... $ cd ....
pvh@arroyo:~/reiser/test/..../..../..../..../.... $ cd ....
pvh@arroyo:~/reiser/test/..../..../..../..../..../.... $ cd ....
pvh@arroyo:~/reiser/test/..../..../..../..../..../..../.... $ cd ..
pvh@arroyo:~/reiser/test/..../..../..../..../..../.... $ cd ..
pvh@arroyo:~/reiser/test/..../..../..../..../.... $ cd ..
pvh@arroyo:~/reiser/test/..../..../..../.... $ cd ..
pvh@arroyo:~/reiser/test/..../..../.... $ cd ..
pvh@arroyo:~/reiser/test/..../.... $ cd ..
pvh@arroyo:~/reiser/test/.... $
Sure, it's right (.... is of type pseudo directory), but I wouldn't want my 
directory tree traversal to ever end up in the bottomless pit of 4dot-doom by 
mistake. 

Crashing and glitching:
pvh@arroyo:~/reiser/ $ cd A2.mp3/...<tab>
freezes the console. I think regular files, when pseudo data is enabled, need 
to provide some basic directory functionality so that users don't 
accidentally blow things up. 

pvh@arroyo:~/reiser/A2.mp3/ $ ls
ls: reading directory .: Not a directory

How would you recommend we implement this so that these errors go away?

Neat stuff:

pvh@arroyo:~/reiser/test/.... $ ls ..
A2.mp3  boo  test
pvh@arroyo:~/reiser/test/.... $ perl
open(N, '>>', 'new'); print(N "newfile"); close(N);
pvh@arroyo:~/reiser/test/.... $ ls ..
A2.mp3  boo  newfile  test
pvh@arroyo:~/reiser/test/.... $    

But what's it for? I was hoping to be able to actually create new attributes 
on a normal file with this, but no dice. It only works for directories.

That's probably more than enough for one night, but we had a real marathon 
session today and have another planned for tomorrow starting in the early 
afternoon. 

Hope people are finding these interesting,
-pvh

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

Re: Plugins: Pseudo-fun.

[Hans Reiser]

Peter van Hardenberg wrote:

>Project update:
>-------------------
>Well, we have wallpapered one of the labs here at UVic with Reiser4 code, 
>printing page after page and taping them together, hanging them on the walls 
>and highlighting them. This was the first time in years that I missed having 
>a dot-matrix tractor-feed printer around. 
>
>Tracing the execution down through the various chains of plugin methods into 
>the plugin set and then into pseudo.c. Pseudo.c is a much better example file 
>than dirc or file.c, the comments are superior and there are many small 
>examples of plugins. Here we had our insights and our inspiration:
>
>Although the overall goal remains elusive, we think we should be able to 
>implement a new Reiser4 pseudo directory in 4dot (/..../). This directory, 
>called "user" will contain per-file user-defined attributes. 
>
Why would these go into the pseudo directory instead of into the directory?

>These will be 
>(if I am using the terminology correctly) grandparent-locality-packed and 
>will be, by convention, very small. (Perhaps the user attributes should be 
>somewhere else? ...attributes vs ...system? I know this is one of those 
>ongoing debates.)
>
>Playing nice with xattr:
>----------------------------
>It is my opinion that xattr support could be added to provide an alternate 
>interface to the same mechanism, thus applications expecting xattr would be 
>able to both read and operate on reiser file-style attributes, a major win 
>for interoperability. Gotta read more.
>
>Big Question of the Day:
>--------------------------
>One big question that follows from today's discoveries and plans: What would 
>be the best method to store these small attribute files? I see no need to 
>reinvent the wheel -- this is a directory -- but how/where do we store the 
>data? Suggestions welcome.
>
>Odd Behavior:
>------------------
>
>Regression problems immediately spring to mind:
>pvh@arroyo:~/reiser/test $ cd ....
>pvh@arroyo:~/reiser/test/.... $ cd ....
>pvh@arroyo:~/reiser/test/..../.... $ cd ....
>pvh@arroyo:~/reiser/test/..../..../.... $ cd ....
>pvh@arroyo:~/reiser/test/..../..../..../.... $ cd ....
>pvh@arroyo:~/reiser/test/..../..../..../..../.... $ cd ....
>pvh@arroyo:~/reiser/test/..../..../..../..../..../.... $ cd ....
>pvh@arroyo:~/reiser/test/..../..../..../..../..../..../.... $ cd ..
>pvh@arroyo:~/reiser/test/..../..../..../..../..../.... $ cd ..
>pvh@arroyo:~/reiser/test/..../..../..../..../.... $ cd ..
>pvh@arroyo:~/reiser/test/..../..../..../.... $ cd ..
>pvh@arroyo:~/reiser/test/..../..../.... $ cd ..
>pvh@arroyo:~/reiser/test/..../.... $ cd ..
>pvh@arroyo:~/reiser/test/.... $
>Sure, it's right (.... is of type pseudo directory), but I wouldn't want my 
>directory tree traversal to ever end up in the bottomless pit of 4dot-doom by 
>mistake.
>
You don't want to have directory traversals use "...." at all.....

> 
>
>Crashing and glitching:
>pvh@arroyo:~/reiser/ $ cd A2.mp3/...<tab>
>freezes the console. I think regular files, when pseudo data is enabled, need 
>to provide some basic directory functionality so that users don't 
>accidentally blow things up. 
>  
>
Why exactly does it freeze things?

>pvh@arroyo:~/reiser/A2.mp3/ $ ls
>ls: reading directory .: Not a directory
>
>How would you recommend we implement this so that these errors go away?
>
>Neat stuff:
>
>pvh@arroyo:~/reiser/test/.... $ ls ..
>A2.mp3  boo  test
>pvh@arroyo:~/reiser/test/.... $ perl
>open(N, '>>', 'new'); print(N "newfile"); close(N);
>pvh@arroyo:~/reiser/test/.... $ ls ..
>A2.mp3  boo  newfile  test
>pvh@arroyo:~/reiser/test/.... $    
>
>But what's it for? I was hoping to be able to actually create new attributes 
>on a normal file with this, but no dice. It only works for directories.
>
>That's probably more than enough for one night, but we had a real marathon 
>session today and have another planned for tomorrow starting in the early 
>afternoon. 
>
>Hope people are finding these interesting,
>-pvh
>
>  
>
I hate to say it, but you are the ones most actively working on this
now, and I encourage you to fix the little bugs you find as you go, and
tell us about them.  Let me know about everything that affects
semantics/functionality before fixing it though....

Hans

Re: Plugins: Pseudo-fun.

[Peter van Hardenberg]

On November 9, 2005 10:02 am, Hans Reiser wrote:
> >
> >Although the overall goal remains elusive, we think we should be able to
> >implement a new Reiser4 pseudo directory in 4dot (/..../). This directory,
> >called "user" will contain per-file user-defined attributes.
>
> Why would these go into the pseudo directory instead of into the directory?
>

Let me construct a simple use case for having a namespace separation between 
contained data and metadata. 

For example, a self-installer or a Klik style bundled package could include 
all its resources within its own directory. In this hypothetical use case, it 
would be very valuable for the package metadata (name, version, description) 
to be clearly differentiated from the package data.

I do not have a strong opinion about whether user metadata should be a sibling 
of fourdot or a child.

> You don't want to have directory traversals use "...." at all.....

No, we really don't. So far, my experiments with ls and grep show them playing 
nicely, but that may only be because '....' doesn't get listed by 'ls -la'.

> >Crashing and glitching:
> >pvh@arroyo:~/reiser/ $ cd A2.mp3/...<tab>
> >freezes the console. I think regular files, when pseudo data is enabled,
> > need to provide some basic directory functionality so that users don't
> > accidentally blow things up.
>
> Why exactly does it freeze things?
>

I have no idea. I suspect tab-completion in my console is waiting for a call 
to file->locate() to come back and doesn't know how to cope when it doesn't.

> I hate to say it, but you are the ones most actively working on this
> now, and I encourage you to fix the little bugs you find as you go, and
> tell us about them.  Let me know about everything that affects
> semantics/functionality before fixing it though....

I'll keep sending out these emails.
-pvh

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

Re: Plugins: Pseudo-fun.

[Hans Reiser]

Peter van Hardenberg wrote:

>On November 9, 2005 10:02 am, Hans Reiser wrote:
>  
>
>>>Although the overall goal remains elusive, we think we should be able to
>>>implement a new Reiser4 pseudo directory in 4dot (/..../). This directory,
>>>called "user" will contain per-file user-defined attributes.
>>>      
>>>
>>Why would these go into the pseudo directory instead of into the directory?
>>
>>    
>>
>
>  
>
I think ..../user/hat-size is too long, and ..../hat-size is just fine
if they go into "....".   The interesting question though is should they
go into .... or into "."  Alternatively, they should go into ".....",
and that way it can be known whether they were created by users and are
things that are not contained by the object but are instead meta data
about the object.

so, we can either call it robert/hat-size or robert/..../hat-size or
robert/...../hat-size or robert/..../user/hat-size, or, perhaps best of
all, call it BOTH robert/...../hat-size and robert/hat-size and also
have a contained-by/ for distinguishing the objects that are contained
in a directory rather than describe the directory, as in
robert/contained-by/stomach

I think I really prefer the last.  Note that it requires 0 lines of code
beyond allowing files to be directories.  Peter Foldiak (it seems we
have two Peters now so I will be forced into formality.....), please
comment on this, as I value your intuition in semantic matters.

>Let me construct a simple use case for having a namespace separation between 
>contained data and metadata. 
>
>For example, a self-installer or a Klik style bundled package could include 
>all its resources within its own directory. In this hypothetical use case, it 
>would be very valuable for the package metadata (name, version, description) 
>to be clearly differentiated from the package data.
>
>I do not have a strong opinion about whether user metadata should be a sibling 
>of fourdot or a child.
>
>  
>
>>You don't want to have directory traversals use "...." at all.....
>>    
>>
>
>No, we really don't. So far, my experiments with ls and grep show them playing 
>nicely, but that may only be because '....' doesn't get listed by 'ls -la'.
>  
>
That was not an accident....

>  
>
>>>Crashing and glitching:
>>>pvh@arroyo:~/reiser/ $ cd A2.mp3/...<tab>
>>>freezes the console. I think regular files, when pseudo data is enabled,
>>>need to provide some basic directory functionality so that users don't
>>>accidentally blow things up.
>>>      
>>>
>>Why exactly does it freeze things?
>>
>>    
>>
>
>I have no idea. I suspect tab-completion in my console is waiting for a call 
>to file->locate() to come back and doesn't know how to cope when it doesn't.
>
>  
>
>>I hate to say it, but you are the ones most actively working on this
>>now, and I encourage you to fix the little bugs you find as you go, and
>>tell us about them.  Let me know about everything that affects
>>semantics/functionality before fixing it though....
>>    
>>
>
>I'll keep sending out these emails.
>-pvh
>
>  
>
Thanks Peter, it is nice to be seeing someone picking this work up when
everyone else is pinned down by kernel inclusion / bug fixing at the moment.

about reiser4 hacks

[Yoanis Gil Delgado]

Thanks a lot for the comments in the mailing list, quite useful. i can see you 
guys are going deep in reiser4 code. meabe i can join your team, and research 
together. i studying resier4 too, 'cause i want to do my thesis in 
filesystems and especially in reiser4.that's all keep hacking ..............

Re: Plugins: Pseudo-fun.

[michael chang]

On 11/9/05, Hans Reiser <reiser@namesys.com> wrote:
> beyond allowing files to be directories.  Peter Foldiak (it seems we
> have two Peters now so I will be forced into formality.....), please

Considering everything you are working on (it's great, by the way -
keep up the good work, we (the users) appreciate it!), this is
probably irrelevant, but you can do what little schoolchildren do:
call them Peter F and Peter H (or Peter van H), provided they agree. 
That should be a reasonable compromise?

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: Plugins: Pseudo-fun.

[Alexander G. M. Smith]

Peter van Hardenberg wrote on Wed, 09 Nov 2005 03:20:32 -0800:
> Odd Behavior:
> ------------------
> 
> Regression problems immediately spring to mind:
> pvh@arroyo:~/reiser/test $ cd ....
> pvh@arroyo:~/reiser/test/.... $ cd ....
> pvh@arroyo:~/reiser/test/..../.... $ cd ....
> [...]
> Sure, it's right (.... is of type pseudo directory), but I wouldn't want my 
> directory tree traversal to ever end up in the bottomless pit of 4dot-doom by 
> mistake. 

I'd considered that before, with MIME types of attributes being an attribute
on an attribute.  Sure, you can ask for it and get it, but for the atomic
attributes (MIME string for one) the ..../whatever is a virtual directory
that's imagined on the fly by the file system, and is read only.  Don't try
to be too consistent - keep in mind that file systems are primarily a tool
for people to use, instead ask if it is useful and whether a crude
approximation to perfection would do.

As for ls and other file system using programs, they'll need to be updated
to avoid getting stuck in infinite loops with hard links anyway.  Or worked
around with some hackery like declaring .... as a symbolic link.

- Alex

Re: Plugins: Pseudo-fun.

[Peter van Hardenberg]

On November 9, 2005 12:38 pm, michael chang wrote:
> On 11/9/05, Hans Reiser <reiser@namesys.com> wrote:
> Considering everything you are working on (it's great, by the way -
> keep up the good work, we (the users) appreciate it!), this is
> probably irrelevant, but you can do what little schoolchildren do:
> call them Peter F and Peter H (or Peter van H), provided they agree.
> That should be a reasonable compromise?

"pvh" is a fine substitute for Peter when there is ambiguity -- I've been 
using it long enough now that it looks like my name to me.

-pvh

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada

Re: Plugins: Pseudo-fun.

[Peter Foldiak]

On Wednesday 09 November 2005 19:31, Hans Reiser wrote:
> Peter van Hardenberg wrote:
> >On November 9, 2005 10:02 am, Hans Reiser wrote:
> >>>Although the overall goal remains elusive, we think we should be able to
> >>>implement a new Reiser4 pseudo directory in 4dot (/..../). This
> >>> directory, called "user" will contain per-file user-defined attributes.
> >>
> >>Why would these go into the pseudo directory instead of into the
> >> directory?
>
> I think ..../user/hat-size is too long, and ..../hat-size is just fine
> if they go into "....".   The interesting question though is should they
> go into .... or into "."  Alternatively, they should go into ".....",
> and that way it can be known whether they were created by users and are
> things that are not contained by the object but are instead meta data
> about the object.
>
> so, we can either call it robert/hat-size or robert/..../hat-size or
> robert/...../hat-size or robert/..../user/hat-size, or, perhaps best of
> all, call it BOTH robert/...../hat-size and robert/hat-size and also
> have a contained-by/ for distinguishing the objects that are contained
> in a directory rather than describe the directory, as in
> robert/contained-by/stomach
>
> I think I really prefer the last.  Note that it requires 0 lines of code
> beyond allowing files to be directories.  Peter Foldiak (it seems we
> have two Peters now so I will be forced into formality.....), please
> comment on this, as I value your intuition in semantic matters.

Thanks. I think it is most important to have naming conventions (at least on 
the long run) that reflect the logical structure and relationships between 
objects AND NOTHING ELSE.
The reason for wanting nothing other than the logical structure is that 
everything else must be arbitrary and must be memorised. I think one of Hans' 
main points in his future vision white paper is that we should not have to 
learn the particular form of organisation that the people who stored an 
object decided to make up, as everything about naming should be "natural" and 
obvious from the logical structure of the objects. (Hans gives examples as 
how bad it is when you have to guess what fields are used in a database.)

So on this list (in connection with part-whole hierarchies) I argued 
previously that paragraph 2 of chapter 3 of a book should be named

book/chapter[3]/paragraph[2]

and not anything else. It should NOT matter whether the person who scanned the 
book decided to put each chapter into a separate "file" (whatever that 
concept will become) or into one big "file" with some way (e.g. markup, e.g. 
XML) to indicate the structure within that "file".
You can read this as "paragraph 2 OF chapter 3 OF the book".
I think I managed to convince Hans that on the long run, it would be much 
better to be able to

cat /home/peter/book

instead of

cat /home/peter/book/..../childcat

which is neither natural or obvious.

The trouble with this example is just that the person using the naming should 
not be required to know how the book is stored (by chapters or as one big 
object). [The whole point of uniting files and directories into objects is 
that this distinction should eventually vanish anyway. What you have on disk 
is a tree structure, and whether you give different parts of that tree should 
just be a matter of convenience. Which bits have metadata connected to them 
is another matter.]

Similarly, I would argue that if you want to know Robert's hat size, you 
should use

Robert/hat-size

and read it as "hat-size OF Robert".
This would be analogous to the conventional /etc/passwd read as "the passwd 
file OF the etc directory".

Another reading of the "/" operator would be "the value of", as in

subject/strike  to/elves  from/Santa

which would read as "the subject IS strike, the sender IS Santa, ..."
(It remains to be seem whether the "IS" and "OF" interpretation of "/" clash 
at some point. I can't see it at the moment.)

Anyway, my point is that if we can implement

Robert/size

for Robert's size then it is much preferable to anything more 
complicated-looking.
Also, possibly

Robert/..../size

should refer to the size of the Robert file (or object), rather than Robert's 
own size. This would be a very useful distinction to be able to make.

 Peter (Foldiak)

Re: Plugins: Pseudo-fun.

[Peter Foldiak]

On Thursday 10 November 2005 12:17, Peter Foldiak wrote:
> one big object). [The whole point of uniting files and directories into
> objects is that this distinction should eventually vanish anyway. What you
> have on disk is a tree structure, and whether you give different parts of

CORRECTION. what I meant to say here was:

"whether you give different names to parts of ..."

> that tree should just be a matter of convenience. Which bits have metadata
> connected to them is another matter.]

Re: Plugins: Pseudo-fun.

[PFC]

> book/chapter[3]/paragraph[2]

I'd rather nitpick this to be :

book/chapters/3/paragraphs/2

simply because this makes little things like enumerating chapters,  
paragraphs etc. easier (not having to do some sprintf("chapter%d",n)),  
also all the items in the chapters/ are of the same "type" which is  
cleaner, and you can also have other attributes in book/ or in a chapter  
without having clutter.

ex :

book/author
book/chapters/1
book/chapters/2
book/chapters/3
book/chapters/4
book/chapters/5
book/title

seems better than

book/author
book/chapter1
book/chapter2
book/chapter3
book/chapter4
book/chapter5
book/title



>
> and not anything else. It should NOT matter whether the person who  
> scanned the
> book decided to put each chapter into a separate "file" (whatever that
> concept will become) or into one big "file" with some way (e.g. markup,  
> e.g.
> XML) to indicate the structure within that "file".
> You can read this as "paragraph 2 OF chapter 3 OF the book".
> I think I managed to convince Hans that on the long run, it would be much
> better to be able to
>
> cat /home/peter/book
>
> instead of
>
> cat /home/peter/book/..../childcat
>
> which is neither natural or obvious.
>
> The trouble with this example is just that the person using the naming  
> should
> not be required to know how the book is stored (by chapters or as one big
> object). [The whole point of uniting files and directories into objects  
> is
> that this distinction should eventually vanish anyway. What you have on  
> disk
> is a tree structure, and whether you give different parts of that tree  
> should
> just be a matter of convenience. Which bits have metadata connected to  
> them
> is another matter.]
>
> Similarly, I would argue that if you want to know Robert's hat size, you
> should use
>
> Robert/hat-size
>
> and read it as "hat-size OF Robert".
> This would be analogous to the conventional /etc/passwd read as "the  
> passwd
> file OF the etc directory".
>
> Another reading of the "/" operator would be "the value of", as in
>
> subject/strike  to/elves  from/Santa
>
> which would read as "the subject IS strike, the sender IS Santa, ..."
> (It remains to be seem whether the "IS" and "OF" interpretation of "/"  
> clash
> at some point. I can't see it at the moment.)
>
> Anyway, my point is that if we can implement
>
> Robert/size
>
> for Robert's size then it is much preferable to anything more
> complicated-looking.
> Also, possibly
>
> Robert/..../size
>
> should refer to the size of the Robert file (or object), rather than  
> Robert's
> own size. This would be a very useful distinction to be able to make.
>
>  Peter (Foldiak)
>

Re: Plugins: Pseudo-fun.

[Peter Foldiak]

On Thursday 10 November 2005 12:26, PFC wrote:
> > book/chapter[3]/paragraph[2]
>
> I'd rather nitpick this to be :
>
> book/chapters/3/paragraphs/2

You are probably right, your version fits the Unix syntax and Hans' syntax 
better. The first version was suggested only to be compatible with XPath 
syntax (so that you could use XPath for the whole filesystem, not just within 
a file [again, blurring the "file" boundary]). I don't know how important 
that would turn out to be.   PF

Re: Plugins: Pseudo-fun.

[Hans Reiser]

Peter Foldiak wrote:

>On Wednesday 09 November 2005 19:31, Hans Reiser wrote:
>  
>
>
>
>So on this list (in connection with part-whole hierarchies) I argued 
>previously that paragraph 2 of chapter 3 of a book should be named
>
>book/chapter[3]/paragraph[2]
>
>and not anything else. It should NOT matter whether the person who scanned the 
>book decided to put each chapter into a separate "file" (whatever that 
>concept will become) or into one big "file" with some way (e.g. markup, e.g. 
>XML) to indicate the structure within that "file".
>You can read this as "paragraph 2 OF chapter 3 OF the book".
>I think I managed to convince Hans that on the long run, it would be much 
>better to be able to
>
>cat /home/peter/book
>
>instead of
>
>cat /home/peter/book/..../childcat
>  
>
yes, but the creator of book should define that book/default is linked
to ..../childcat, and should be able to make it something else if he
chooses.

Re: Plugins: Pseudo-fun.

[Peter Foldiak]

On Thursday 10 November 2005 17:16, Hans Reiser wrote:
> >cat /home/peter/book
> >
> >instead of
> >
> >cat /home/peter/book/..../childcat
>
> yes, but the creator of book should define that book/default is linked
> to ..../childcat, and should be able to make it something else if he
> chooses.

Yes, it should be possible to make it something else. But perhaps if all you 
want is simple concatenation, that could be automatic (unless something else 
is specified).

(And should it be book/..../default, after all, isn't this typical metadata?)

What is the best way to specify such an object "constructor"?
(Should it be just a script? But that wouldn't work in the kernel, right?)
 PF

Re: Plugins: Pseudo-fun.

[Hans Reiser]

Peter Foldiak wrote:

>On Thursday 10 November 2005 17:16, Hans Reiser wrote:
>  
>
>>>cat /home/peter/book
>>>
>>>instead of
>>>
>>>cat /home/peter/book/..../childcat
>>>      
>>>
>>yes, but the creator of book should define that book/default is linked
>>to ..../childcat, and should be able to make it something else if he
>>chooses.
>>    
>>
>
>Yes, it should be possible to make it something else. But perhaps if all you 
>want is simple concatenation, that could be automatic (unless something else 
>is specified).
>  
>
it should be the default default, yes....

>(And should it be book/..../default, after all, isn't this typical metadata?)
>
>What is the best way to specify such an object "constructor"?
>(Should it be just a script? But that wouldn't work in the kernel, right?)
> PF
>
>
>  
>

Re: Plugins: Pseudo-fun.

[Peter van Hardenberg]

On November 10, 2005 04:36 am, Peter Foldiak wrote:
> On Thursday 10 November 2005 12:26, PFC wrote:
> > > book/chapter[3]/paragraph[2]
> >
> > I'd rather nitpick this to be :
> >
> > book/chapters/3/paragraphs/2
>
> You are probably right, your version fits the Unix syntax and Hans' syntax
> better. The first version was suggested only to be compatible with XPath
> syntax (so that you could use XPath for the whole filesystem, not just
> within a file [again, blurring the "file" boundary]). I don't know how
> important that would turn out to be.   PF

PF, I intend to work on a(n inefficient) proof-of-concept xPath shell once 
this attribute notation / storage mechanism is finished.

-- 
Peter van Hardenberg (pvh@pvh.ca)
Victoria, BC, Canada