[GRASS5] GRASS 5 and sockets: default?
grass at geni.cemtlo.com
Mon Feb 19 19:58:59 EST 2001
From: Markus Neteler <neteler at geog.uni-hannover.de>
> 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
> > know?
> Maybe this can be borrowed from d.zoom. Huidae may be able to tell us more
> about it (tomorrow).
The similar code is in src/display/d.zoom/cmd/main.c and
cmd = (char *)G_malloc(strlen(list)+1);
for(i=1; i<nlists; i++)
cmd = (char *)G_realloc(cmd, strlen(cmd)+strlen(list[i])+2);
make a backup of drawing commands.
recreates erased maps.
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