9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Multi-dimensional filesystem
Date: Thu, 16 Aug 2012 17:41:30 +0200	[thread overview]
Message-ID: <20120816154130.GA551@polynum.com> (raw)
In-Reply-To: <a6ad26edff71afa979ad715b906ed865@brasstown.quanstro.net>

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



  reply	other threads:[~2012-08-16 15:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-03 17:18 tlaronde
2012-08-03 18:58 ` Skip Tavakkolian
2012-08-03 19:25   ` tlaronde
2012-08-03 21:08 ` Burton Samograd
2012-08-03 21:12   ` Kurt H Maier
2012-08-03 21:17     ` Burton Samograd
2012-08-04  6:13   ` tlaronde
2012-08-04 10:56     ` Aram Hăvărneanu
2012-08-04 15:00       ` tlaronde
2012-08-04 12:16 ` Nicolas Bercher
2012-08-04 15:20   ` tlaronde
2012-08-05 15:29     ` Charles Forsyth
2012-08-05 17:36       ` tlaronde
2012-08-15 16:04         ` Eugene Gorodinsky
2012-08-15 17:33           ` tlaronde
2012-08-15 20:09             ` Bakul Shah
2012-08-15 20:17               ` erik quanstrom
2012-08-15 21:00                 ` Bakul Shah
2012-08-16  1:38                   ` erik quanstrom
2012-08-16  4:06                     ` Bakul Shah
2012-08-16 13:45                       ` erik quanstrom
2012-08-15 21:27               ` tlaronde
2012-08-16  3:47                 ` Bakul Shah
2012-08-16  5:34                   ` tlaronde
2012-08-16 13:40                     ` erik quanstrom
2012-08-16 15:41                       ` tlaronde [this message]
2012-08-16 16:06                         ` erik quanstrom
2012-08-16 16:28                           ` tlaronde
2012-08-16 15:59                       ` Bakul Shah
2012-08-16 16:31                         ` tlaronde
2012-08-16 16:48                         ` Burton Samograd
2012-08-16 17:02                 ` Eugene Gorodinsky
2012-08-16 19:48                   ` tlaronde
2012-08-16 20:11                     ` erik quanstrom
2012-08-17  6:48                       ` tlaronde
2012-08-17  7:48                         ` Lucio De Re
2012-08-20 15:17                           ` tlaronde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120816154130.GA551@polynum.com \
    --to=tlaronde@polynum.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).