[GRASSLIST:3161] Re: [GRASS5] Re: Grass GUI
Eric G. Miller
egm2 at jps.net
Sun Feb 17 21:05:21 EST 2002
On Mon, Feb 18, 2002 at 01:06:14AM +0000, Glynn Clements 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:
> you would have:
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:
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
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>
More information about the grass-dev