[GRASS5] Platform for next generation UI

[Glynn Clements]

Trevor Wiens wrote:

> When I had asked the question I was thinking of read access and the
> possibility of multiple views of the same location could be useful with
> frames for cartographic purposes. However,...

OK. You can already have multiple sessions reading from the same
mapset, either by specifying an explicit mapset using the map at mapset
syntax or by adding the mapset to the mapset path with g.mapsets.

This is still technically unsafe; if you try to read a map which is
being created or updated, the results are undefined.

For a single user with multiple sessions reading a mapset and
(optionally) one session modifying it, it isn't that hard to ensure
that problems don't arise. The risk is more significant if one user is
reading another's mapset and the two aren't coordinating their usage.

> --- thinking out loud follows ---
> 
> For modification I would expect that one wouldn't want more than one
> individual modifying a given vector or raster file at the same time, no
> matter how sophisticated your implementation. Nor can I see (at this
> moment) any real practical benefit to doing so. However, for managing
> the modification of individual layers, their creation, deletion, etc.,
> such a scheme could be setup by managing all a locations data in a
> database like PostgreSQL because modern databases have all the
> facilities already written to manage these types of problems. What I'm
> thinking about is a database of environment settings, vector and raster
> file names, state, ownership, etc. Individual modules would have to be
> modified to first check against the database if they had permission to
> perform an action. Since the problem would be identical for each module
> so this would only need to be written once. One potential roadblock is
> this creates more dependencies for GRASS, but since there is talk of
> integrating SQLite, it might be sufficient (I've never used it so I
> don't know).

The main issue is with modules which read and/or write multiple maps. 

Each module would need to acquire locks on all of the maps which it
will be using at the outset, and release them all upon completion.

This really needs to be done in the module itself, as the libraries
only get to "see" individual maps being opened and closed.

-- 
Glynn Clements <glynn at gclements.plus.com>