[GRASS5] Platform for next generation UI
twiens at interbaun.com
Wed Jan 4 01:18:58 EST 2006
On Tue, 3 Jan 2006 15:56:11 +0000
Glynn Clements <glynn at gclements.plus.com> wrote:
> Trevor Wiens wrote:
> > > > > + Minimising dependence upon global state (WIND, $GISRC, monitor pads,
> > > > > etc).
> > > >
> > > > I would expect this would be highly desirable to addressing issues of
> > > > having multiple users accessing a single location at one time.
> > >
> > > That situation is harder to solve.
> > Yes, but wouldn't it be logical to try to solve that at the same time
> > since this is a desirable feature and we only need to make the changes
> > once?
> No. By "harder", I mean "several orders of magnitude harder".
> Minimising dependence upon global state is a relatively simple matter
> of modifying the functions which query that state to allow the values
> to be overriden, so that the global state simply becomes a default.
> A concrete example: modifying the functions which read the WIND file
> to first check for an environment variable (e.g. WIND_OVERRIDE) and,
> if set, read the file to which that variable refers instead. That
> would allow the GUI to run commands using a specific region without
> having to modify the WIND file (which could interfere with other any
> other commands which were running).
> [The redraw-on-resize functionality built into XDRIVER involves
> something similar; R_open_driver() first checks for the environment
> variable MONITOR_OVERRIDE, and only uses the MONITOR setting in $GISRC
> if that is unset. This allows a monitor to redraw itself even when it
> isn't the active monitor.]
> Making it so that multiple commands could safely modify a given mapset
> concurrently would require adding fine-grained locking to every
> module, including deadlock detection, inheritable locks etc. That is a
> vast amount of work just to implement, let alone the design issues.
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,...
--- 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
Clearly this is beyond the scope of current development
plans but if it isn't an entirely bad idea brought on by sleep
deprivation, it might be worth thinking about for the future.
twiens at interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
More information about the grass-dev