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

[Eric G. Miller]

On Mon, Feb 18, 2002 at 01:06:14AM +0000, Glynn Clements wrote:
[snip]
> 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.  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...


> 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.

> 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.
It might be better to have d.mon driver=PNG name="/path/to/file"
which could eliminate one environment variable.  File based
drivers would take "name" to be a file path, whereas interactive
monitors would take it as their window name.  I dunno, think that
need some more thought...

-- 
Eric G. Miller <egm2 at jps.net>