On Wed, Aug 15, 2012 at 08:47:47PM -0700, Bakul Shah wrote:
>
> > 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.
>
> Looks like you are treating ".+" & ".-" specially *somewhere*.
> Are foo/.- and foo/bar treated differently? What would
> "foo/.-" even mean? What would open("foo/.-", mode) do?
They are treated specially by the server serving 9P requests. The aim
would be to present a classical file hierarchy, even with special
conventional names, implementing multiple parents, by convention,
under .-/, and (classical) multiple children by .+/.
.+/ holds the children (if the requested node has ones).
.-/ holds the parents (in reverse order i.e. the nearest parents up in
every dimension).
./* being the siblings of the node (siblings, whether files or
directories appear by name not hidden under .+/ or .-/).
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.
But the result is that going "up" means going down (from the view
served) to the next hierarchy level in .-/.
>
> When I try to work out an example I don't get how you can
> implement this. May be you can use your special syntax to
> present an example or two as shell scripts?
>
> In any case since multiple relationships are possible, why
> single out a specific case? That is, it seems to me you can
> either use the current 9p as is and implement what you want by
> convention in your programs or extend the model in a major way
> (which is where I was going).
The two approaches are not mutually exclusive. I mean one can
implement using the current 9p (to see if it works, what are the
limits, and the benefits...); and later tackle a more refined and
perhaps more general answer the way you are describing.
Plus, for a more broader view, I am---as I think a lot of
users/programmers---not absolutely happy with relational databases.
For example, for KerGIS, I have implemented, for attributes linked
to geometry, a library, with a SQL backend (for use with PostgreSQL),
a DBF (mainly for ESRI(R) Shape support), and a stdout and a stdin
to be able to have a text format and simply pipe to utilities to
save, fill or convert between databases.
Mostly, PostgreSQL for a normal use (of KerGIS) is overkill. And
the SQL type does not allow the kind of relationships I want---multiple
parents are difficult, or rely on processing the data for some indexing;
to have a list in one field, without specifying a length is not there
etc.
Having a file system organizing the relationships between
the data, and implementing, one can say, the indexing by its very
structure, and allowing to retrieve "records" or "fields" by the
file system would be ideal (a small loss of time is not a problem).
Not to say that once ownership, locking etc. is made by a fileserver,
you have a distributed system for free---a lot of GIS softwares
are using relational database even to store geometry! (a disaster
from an efficiency standpoint when one is making geometrical
manipulations---processing spaghettis and so on), simply because
this relieves the developers/programmers from the distributed
problems: they let the database server handles this; IMHO if
databases are so pervasive nowadays, this is because of this.
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
