[GRASS5] Re: XDRIVER todo

[Markus Neteler]

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'