[GRASS5] GRASS 5 and sockets: default?
neteler at geog.uni-hannover.de
Mon Feb 19 14:03:56 EST 2001
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?
> 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
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 :-)
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