[GRASS5] Proposal for a GRASS daemon to deliver metadata

[Markus Neteler]

Hi all,

concerning the daemon discussion (to daemon or not to daemon):
We are currently facing a set of problems which should be fixed
in near future. If a daemon is required - I don't know.
THe problems are totally different, some of those listed
below might belong to another discussion.

What's required (partly already implemented):

- external applications like "R" needs to get the
  metadata (location, mapset, resolution, projection)
- external applications should be able to set new
  location parameters easily (like R, web applications,...)

- if storing entire datasets into PostgreSQL (or another DBMS)
  the metadata needs to stay somewhere. Suppose we
  analyse GIS data in R, taking vectors directly from
  GRASS using the GRASS/R interface and taking raster data
  delivered by PostgreSQL (using the RPgSQL or RODBC proxy),
  how to keep the location settings in sync? The basic
  problem will arise from data storage in PostgreSQL
  if one wants to analyse a subset of data only.

- database locking will be required (already implemented)
- but: concurrent GRASS sessions should be possible, at
  least with different locations (so a daemon could check
  for conflicts, environment variables might not be sufficient)

- changing location on-the-fly should be possible (daemon
  might not be required)

- the monitor should be closeable by click without the
  "d.mon stop" command (for user's convenience). This will
  require the fifos exchange to a sockets concept
- monitor locking is required (already implemented)


Most of these topics are concerning user's convenience. For
wider GRASS acceptance I feel we should take care of this.

Just some discussion comments,

 Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'