On Thu, Aug 16, 2012 at 09:40:22AM -0400, erik quanstrom wrote:
> > What is more bizarre, with my scheme, is how to implement the meaning
> > of ".."? If classical clients have to be able to be used, the server
> > must create a fake name (as the penultimate component of the
> > dirpath), that triggers the correct answer from the server.
>
> see defmnt.c:/^fixdotdotname for where this is handled by the kernel,
> not the file server.
Well, I find cleanname (libc/port/cleanname.c) doing the .. dance with
compression. But nothing in the kernel proper..
Except by allowing a new syntax .../{a,b,c,d}/foo meaning that foo has
a, b, c and d as parents, the only way I see things working with the
utilities and the ".." treatment is to insert a special name ensuring
that a ".." suppression leading to this name will trigger the correct
answer from the fileserver.
I don't say that the fileserver has to treat directly the ".." in
a path specification: the cleaning is made on the client side before
the 9P request is sent. I mean that for this to work, the fileserver,
from the first mount, will have to create special names (a uniq
name, or the {a,b,c,d} lexeme if the user can have a chance to have
a representation of the graphs that bear some meaning) so that a
request of the content of this special name delivers the correct
view of the data (if "classical" utilities are used to browse the
file hierarchy).
And by the way, since the parents a, b, c, d can be in several
dimensions, and not having the same scalar value as a coordinate
(`a' being direct child of /; `b' being deep in multiple directions
etc., going up is not going up 1 in every dimension...), going to
the "parents" would not mean anything, and the best to do would be
to present a fake "middle" node where {a, b, c, d} appear in .-/
(parents), the children of {a,b,c,d} in .+/, and nothing in ./
(user to decide precisely where in a named node, he wants to go,
standing in between for the moment).
In a more general term, as projective geometry gives rules to
represent a 3D objects on a 2D plane, is it possible to represent
multiple dimensions in a single dimension string? The answer is
yes, since this is what the n-uples coordinates representation is and
since our linear languages "speak" about multidimensional features even
when we have strictly no intuition about these "spaces".
Can this be user friendly? No, if there are a lot of links, and
long enumerations. But the naming of the nodes is always a problem
(lengthy names, spaces, discrimining characters being put last and
not first bringing identical long prefixes etc.).
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
