[GRASS5] Proposal for a GRASS daemon to deliver metadata

[Bernhard Reiter]

Hi all,
I am thinking about this daemon idea for a couple of minutes now
and as Justin I still fail to see the need for it.
This only shows that the problem and the proposed solution
is not explained enough and in a way that I can grasp it easily.

Let me give you my thoughts on the original idea:

On Fri, Aug 25, 2000 at 11:08:45AM +0100, Markus Neteler wrote:
> we got the idea that a GRASS daemon might be great to solve a couple
> of problems.

> Roger needs the GRASS metadata (location parameters) to be know
> for his R-statistics interface. Currently this is done by reading
> the environmental variables, but this is not very elegant and
> efficient. 

It is basic, but is works nicely. But it is also simple.
This being non elegant or efficient does not create a reason
to change it in my eyes, because it is good enough for the task.

> To have a daemon serving these data would be quite
> good even for other applications coupled to GRASS.

Why? The daemon how I understood so far would just be a database
for environment variables, just like a global dictionary.
But this is exactly what environment variables are.

I can see two possible advantages of the daemon:
	- It might check dependecies and notify _running_ programms
	that they have to take action. So another part of grass
	would register and get's called back.
	But this is much more than being a daemon, this would
	be a major redesign of grass, to have a core.

	- It might serve more than one location.
	(Though again this is like running more than one grass
	session.)

> And the (hopefully forthcoming) new XDRIVER with sockets may
> make use of it, too.

How? The communication between the grass-database part and the
x11 display part is very special and has nothing do to with
the grass database, I presume.

> Maybe (you will know that better than me) it is a way to make
> possible location changes on-the-fly.

No. Why should it.
Just changing the environment variables or the variables held by 
the daemon is not more or less difficult.

> Probably it could be useful too in order to set
> up parallel GRASS sessions without locking. And maybe they could
> talk to each other and share the workload on different CPU's? A
> simple "parallel GRASS"?

If you work on a database file, you have to lock it.
If you have one graphical display (e.g. monitor) you have to lock this.

We could thing about introducing read only locks and write locks, 
this is entirely on the locking mechanism intelligence part.
Then we might start two grass processes on the same environmental 
variables and this would be the most basic paralleling in GRASS.

And the next step for paralleling in GRASS I see is to make selected
single grass commands work parallel inside.

	Bernhard
-- 
Professional Service around Free Software                (intevation.net)  
The FreeGIS Project				            (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20000829/cacba3a9/attachment.bin