From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 16 Aug 2012 17:41:30 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120816154130.GA551@polynum.com> References: <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> <20120815200949.4628BB85B@mail.bitblocks.com> <20120815212734.GA1190@polynum.com> <20120816034747.7FE5EB85B@mail.bitblocks.com> <20120816053428.GA427@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: aa1e5e4e-ead7-11e9-9d60-3106f5b1d025 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 http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C