On Wed, 15 Aug 2012 19:33:27 +0200 tlaro...@polynum.com wrote:
>
> The main differences from what I have in mind are:
>
> 1) There is no general relational database concept: the relationships of
> the "records" (files, that can have both a text content [the definition
> in my example] and be a directory node) is exclusively isomorphic to
> coordinates: (i, j, k, ...).
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.
> 2) There is no constraint in the size of the "fields": the dimension can
> grow with time (no given dimensions coordinates being, by convention,
> equal to 0 to reach the actual dimension) ; there is no limit (except
> implementation one) for the size of an enumeration.
>
> 3) The hierarchy is the user interface, to view and to add the data: a
> new file (record) is added by placing it in the hierarchy; while in a
> relational database, the indexing is deduced from the actual records;
> here, so to say, the data is entered through the indexing.
>
> 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.
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 :-)
