From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Wed, 15 Aug 2012 19:33:27 +0200." <20120815173327.GA424@polynum.com> References: <20120803171847.GA2720@polynum.com> <501D12A1.1060906@yahoo.fr> <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> Date: Wed, 15 Aug 2012 13:09:49 -0700 From: Bakul Shah Message-Id: <20120815200949.4628BB85B@mail.bitblocks.com> Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: a9b5ca82-ead7-11e9-9d60-3106f5b1d025 On Wed, 15 Aug 2012 19:33:27 +0200 tlaronde@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 :-)