[GRASS5] Re: XDRIVER todo
neteler at geog.uni-hannover.de
Wed Feb 7 04:25:02 EST 2001
[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:
> 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
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,
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev