[GRASSLIST:3161] Re: [GRASS5] Re: Grass GUI

[Glynn Clements]

Eric G. Miller wrote:

> > It isn't meant to be an alternative; the "one session per user"
> > limitation should be removed regardless. The "one session per mapset"
> > issue is harder to resolve. It would be easier if the lowest level of
> > the directory layout were switched, so that each map was a
> > self-contained directory. I.e. instead of:
> > 
> > 	cell/foo
> > 	cellhd/foo
> > 	cell_misc/foo/*
> > 
> > 	cell/bar
> > 	cellhd/bar
> > 	cell_misc/bar/*
> > 
> > you would have:
> > 
> > 	foo/cell
> > 	foo/cellhd
> > 	foo/cell_misc/*
> > 
> > 	bar/cell
> > 	bar/cellhd
> > 	bar/cell_misc/*
> 
> Such a layout would be similar to an Arc/Info workspace, 'cept we
> don't have an "info" directory.  I still prefer the idea that
> all the data sets in a LOCATION are in the same coordinate
> system.

I agree, in the sense that it should be possible to check if one map
is in the same "location" as another (or as the "current" location)
without having to compare all of the various parameters (ellipse,
datum, projection, zone etc).

However, that doesn't necessarily mean that a location has to be
implemented as a common parent directory.

> A while back, we talked about moving things around like:
> 
>   GISDBASE/LOCATION/MAPSET/
>        vector/
>           foo/
> 	  bar/
> 	  baz/
>        raster/
>           aaa/
> 	  bbb/
> 	  ccc/
>        sites/
>           ddd/
> 	  eee/
> 	  fff/
> 
> with some other possible entries.  Then, within a given mapset,
> you could lock vector/foo either via open() calls or via
> a lockfile mechanism.  Using open() could lead to races, but
> using lockfiles leads to potentially stale files blocking
> access.  Perhaps there are other/better ways...

Some comments:

1. I'd like to do away with the $GISDBASE concept altogether. It
doesn't sit at all well with typical access control mechanisms. Of
course, a more general mechanism wouldn't prohibit collecting all of
the data under a common "root" directory, if that was desired.

2. I don't really see any advantage to imposing the
vector/raster/sites level.

3. I'm thinking in terms of a "map directory" being completely self
contained, so it would basically correspond to a "document". Such
directories could exist anywhere, in the same way that most
applications can access data files in any directory, with the
possibility of specifying a map using an absolute path.

There would also need to be some $PATH-like mechanism, so that the
user isn't forced to use absolute paths. Basically, something which
enables the use of the current layout, but without *requiring* any
particular layout.

As for locking: if each map were a directory, the simplest approach
would be to use a kernel lock (lockf, flock, fcntl) on a specific file
in the directory (e.g. cellhd, or even a dedicated file). 
Unfortunately, not all NFS environments support kernel locks, so a
lockfile might be preferable (although lockfiles suffer from the risk
of stale locks).

> > There's also the fact that the current directory hierarchy of
> > $GISDBASE/$LOCATION_NAME/$MAPSET requires that $GISDBASE is
> > world-writable (so that users can create new locations) and that each
> > location directory is also world-writable (so that users can create
> > new mapsets).
> 
> Yea, this is nonsense.  Part of this has to do with the colr2/
> thingy.  Anyway, I'd think we could scrap the mapset concept
> altogether using a GISDBASE/LOCATION/<feature class>/<feature>/
> type layout.  But, that'd be fairly radical.

I suspect that you can get a lot more radical than that without having
to change too much code (i.e. you might need to change libgis, but not
the applications).

AFAICT, the only thing that would be hard (and probably undesirable)
to change is the requirement that the components (cellhd, cell, colr
etc) are separate files. Code which contains assumptions about
relative locations (other than libgis itself) should probably be fixed
anyway (with new functions added to libgis if necessary).

> > BTW, Eric's change to the monitor socket path potentially makes
> > matters worse for web applications. Whereas monitor names were tied to
> > a mapset (i.e. you used to be able to have multiple instances of
> > "d.mon start=PNG", provided that each had a different mapset), now
> > they are tied to a UID. So now you would have to "allocate" monitor
> > names.
> 
> One of the problems that change meant to overcome was the limitation
> on path length for UNIX sockets.  It could be modified if there
> was a session id mechanism.  It might be more flexible if we had
> a monitor name method anyways.  Consider, that with sockets, that
> the number of X monitors is only an arbitrary restriction now.

Yep.

> It might be better to have d.mon driver=PNG name="/path/to/file"
> which could eliminate one environment variable.

I was thinking along similar lines, specifically something like:

	d.mon start=x0 driver=XDRIVER path=/path/to/socket

"driver=" and "path=" would be optional, with the former obtained from
etc/monitorcap and the latter computed. A short name is useful for
interactive use; "d.mon select=x0" would be preferable to
"d.mon select=/path/to/socket"

FWIW, X suffers from exactly the same problem, i.e. finding an unused
display name if you're starting a "virtual" X server (e.g. Xvnc) on a
multi-user system.

-- 
Glynn Clements <glynn.clements at virgin.net>