On Wed, Aug 15, 2012 at 01:09:49PM -0700, Bakul Shah wrote:
>
> Sounds like you want to represent a node with a directory,
> that has a "content" file that stores content associated with
> this node and a bunch of links to other nodes. You are most
> interested in parent/child relationships so for instance you
> can store links to all parents in a "parent" file and links to
> all children in "children" file. Not suggesting this is how
> you implement it; I am just trying to understand. A concrete
> example from you would help.
>
I will give two (DeLuxe(R) version!) examples.
First one, related to what I was wandering about, is mathematical
definitions and relationships. Take the picture of the first volume of
van der Waerden's Albebra (I have the german edition and will keep the
german words). We speak about links between notions presented in a
linear order: the order of the chapters:
Galois theory chapter is the descendant of concepts from
Vektorräume, Fortsetzung der Gruppentheorie and Körpertheorie chapters;
Vektorräume and Gruppentheory being siblings ("children" of Ringe und
Körper) while Körpertheorie is a grand-child of Vektorräume.
Example of multiple parents, and not at the same level.
Second example: field parcel (surveyor work). One can divide a parcel,
leading to several children. But one can also reunite several adjacent
parcels leading to one uniq new, all the inner borders being
suppressed. This new parcel has several parents. And the "child" is
bigger than every "parent" taken alone...
> >
> > 4) And the problem was also thought through 9P: is there something in 9P
> > that would prevent, at least theoritically, such a view of data to be
> > presented? With the convention of ".+" and ".-", my answer is no: 9P has
> > no hardcoded knowledge of ".." if I'm not mistaken.
>
> Note that in Unix ".." came for free since each dir stored the
> inode number (a "link" to an anonymous inode) along with a
> name. The scheme could represent any graph but the kernel
> restricted it to a tree by disallowing links to directories.
> Expanding this back to multiple parents in effect makes a
> poset (partially ordered set) but the unix trick or storing
> (parent-inode, "..") fails. Treating ".." as an /operator/
> that cancels the previous component in a path also fails.
Yes.
>
> You can perhaps extend a symlink object to store multiple
> links as I described above. The other difficulty is that
> something like 9p will only yield zero or one object as you
> traverse a path. How do you handle multiple parents?
>
> A more general idea is to consider a path component a "graph
> expression" component that is interpreted by the current node
> and may yield *any number of* new nodes.
>
> In other words
>
> x = open("a/b/c", mode)
>
> can yield a vector of file descriptors! Leaving component
> interpretation to the current node makes this a very dynamic
> and powerful system (for example, one can think of a node that
> maps to a list of network nodes -- so something like
>
> echo "date" > /net/my-nodes/foo
> chmod +x /net/my-nodes/foo
> /net/my-nodes/foo
>
> can run date on all my nodes! This would be a very compact
> expression of how to distribute data or work.
>
> Your original query is vague enough (& confusing, at least to
> me) that one can take it in a number of directions :-)
I don't claim that my question was "definite" and it was open. So every
idea "wandering" around this fuzzy concept is OK :-)
But in my idea, there would be several distinct things (and I think
plan9 has already split the things making alternative view possible):
1) There is the storage of the "things". This is mostly orthogonal---the
trick being, as always, to be able to retrieve efficiently the stuff but
really starting from the coordinates (i, j, k, ...).
2) In 9P, the ".." if I'm not mistaken is not here. One can request a
file, or go back to the previous one. The ".." including "path removing"
is not implemented in 9P if I read correctly the manpage. So a client
can speak 9P, but the way the stuff are presented will be mainly in the
server, the trick to allow existing clients to browse being this ".+"
and ".-": ".+" leads to children; ".-" leads to parents and a DESC file
being perhaps a text description, and some fake parenting allowing a
request of ".." to trigger a special action from the server---but all
these are artefacts of the server.
3) This is the server that offers a "view" of the data. And in this
case, indeed, a request for "something" can trigger "bizarre" actions.
>From a very cursory look, it seems to me that it could be simpler to
implement this with Plan9, because it is relatively agnostic about what
is a filesystem, than with an Unix if I take into account the
difficulties Unix kernels have with userland filesystems---probably
because a lot of semantics are assumed in the vnode subsystem.
By conception, Plan9 makes a distinction between viewing the data
(terminal), processing the data (CPU) and serving the data (fileserver).
This is the case here, and this is not a surprise since these
distinctions are quite natural---the terminal/CPU/fileserver being
simply the special case where the three happen to be the very same
machine. But this is a coincidence, not an obligation.
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
