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