Eric,
[presuming your o.k.: cc to grass5 - it's of wide interests]
On Tue, Feb 06, 2001 at 07:03:21PM -0800, Eric G . Miller wrote:
Markus,
I know I haven't been doing much on CVS lately (I'm trying not to break
stuff -- at least, that's my excuse and I'm sticking to it ;).
Eric, I am already feeling better (have been sleeping well) 
Yesterday I was quite embarrassed as building binary tarballs
is far from being automated and I didn't want to start again.
But using the quick solution and simply adding the missing script to
the ball did the job.
Anyway, I know there's been a lot of work trying to get this IPC thing
working, and it does work, but I don't like it. It's a short term
solution that introduces other problems (leaving message queues
behind...).
Yes, probably, as you kindly already have been developing sockets
functions, we should concentrate on this.
Now, I've done some work here with a local sockets based solution, and
it does work, but it requires lots of small modifications all over the
GRASS sources (as mentioned in the mail I sent). Of the three things in
the TODO list, it *does* handle the click to close nicely. It also, by
design, has the side benefits of:
1) No "dev" directory or FIFO are necessary.
2) All "devices" are localized to the user's current mapset and no
lock files are needed.
3) Implements a method for other interprocess communications and puts
it in libgis where it belongs.It may be possible to do the autoredraw from the PAD, as I don't think
there will be any process group issues. I don't think the mapscale
thing in the title is very easy to do -- it's a good idea though.
So many side benefits from sockets - for me it is definitly no question
any more to do it! [The only thing is not to do it during test phases,
but we all have learned our lesson.].
I guess I'm bugging you because I think this solution could address
several things simultaneously (including the XDRIVER). It *would*
cause a bit of instability for at least a little while, so I'm not going
to push it very hard. I just want you to consider it (take a look at
how trivial the unix_socks.c functions are -- yet it simplifies many
things in SWITCHER.c). I don't want to step on any toes, but I just
feel this IPC solution is fundamentally not the way to go.
Then we should stop working on it and push the sockets thing!
I am willing to help where I can...
Have a better tomorrow,
I already have
Thanks for your notes,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'