[GRASS5] GRASS 5 and sockets: default?

[GRASS]

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?
> 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).
> 

The similar code is in src/display/d.zoom/cmd/main.c and
src/display/d.zoom/cmd/redraw.c.

in src/display/d.zoom/cmd/main.c:

	cmd = (char *)G_malloc(strlen(list[0])+1);
	strcpy(cmd, list[0]);
	for(i=1; i<nlists; i++)
	{
		cmd = (char *)G_realloc(cmd, strlen(cmd)+strlen(list[i])+2);
		strcat(cmd, "\n");
		strcat(cmd, list[i]);
	}

make a backup of drawing commands.

in src/display/d.zoom/cmd/redraw.c:

	system(cmd);

recreates erased maps.


Huidae Cho

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