[GRASS5] GRASS 5 and sockets: default?

[Markus Neteler]

On Mon, Feb 19, 2001 at 09:34:22AM -0800, Eric G. Miller wrote:
> On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:
> > Hi all,
> > 
> > the sockets driver is maturing quickly. Question is if
> > we should make it default for the forthcoming 5.0.0
> > or not. 
> > 
> >  - we need a platform report about it's quality
> >      o Linux: running well (better than fifos)
> >      o SGI:
> >      o Windows/Cygnus:
> >      o FreeBSD:
> >      o Solaris2.6/SUN: running well (better than fifos)
> >      o Solaris8/SUN:
> >      o Solaris/Intel:
> 
> Yes, I'd like to hear a few more reports first.  Does it work okay on
> CygWin? and every other target platform?
> 
> >  - what's missing (hi Eric)
> >         - locks directory moved to $HOME/.grass5/ (?)
> 
> Correct me if I'm wrong, but the global lock directory was only used for
> monitors under the fifo scheme?
Yes.

> The sockets code doesn't use/need any
> such locks (drivers only handle one connection at a time -- all other
> connections wait or are refused; users no longer share a limited
> resource like fixed fifos).
O.k. But there was something with long path names and sockets:

> However, I like the $HOME/.grass5/ directory for other reasons.  There's
> already the G_home(), so it's only a little bit of work to set up
> element handling (e.g. subdirs).  I want to make sure ~/.grass5 is chmod
> 4700 for a modicum of security.  Is there a reason we might want it
> readable by processes not owned by the $USER?
I don't think so. $USER should be sufficient.

> >  - what's to be postponed to 5.1:
> >         - scale in top line of monitor (?)
> 
> In theory, this doesn't seem real hard (you already have put together
> some working code).  However, there's the problem where the server
> process is never "informed" if a user changes region settings midstream.
> So, somewhere there'd have to be a mechanism for requery/update of the
> title bar.
Mhhh, what about d.zoom? Maybe it can talk to the XDRIVER?

> >         - auto-redraw when resizing  (?)
> 
> This seems to be more difficult, when you consider frames in addition to
> the window itself.  The current code just deletes everything from the
> PAD list, clears the screen, and sets up a new pixmap buffer (if
> necessary).  It would be nice to have, and seems like it should be
> doable.  I think the resize code maybe needs to make a backup of the
> PAD, and then try to recreate the commands after the resize.  I don't
> know?
Maybe this can be borrowed from d.zoom. Huidae may be able to tell us more
about it (tomorrow).

> > I have the impression that the sockets driver is the last thing
> > missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
> > We won't be able to get G3D stable, so that will be postponed to
> > GRASS 5.1 (and left out of 5.0.0).
> 
> I agree that the g3d stuff isn't really ready for prime time.  There's
> little that you can do with the data right now anyway, so maybe we give
> it a hard look in 5.1?
Yes. I'll add that to the 5.1 proposal.

> > What about the NVIZ troubles? I cannot reproduce Helena's problems.
> 
> I dunno.  Those compass marks make a big difference in understanding
> what the controls are doing (thanks Bob).

As Helena reported the NVIZ display problem seems to be minimized.
Hopefully enough to call it stable :-)

Markus

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