[GRASS-GUI] Re: [GRASSGUI] wxgrass wishes: have 1 GUI window instead of many

[twiens]

----- Original Message Follows -----
From: Glynn Clements <glynn at gclements.plus.com>
To: Trevor Wiens <twiens at interbaun.com>
Cc: Jachym Cepicky <jachym.cepicky at gmail.com>,
grass-gui at lists.osgeo.org, michael.barton at asu.edu,
neteler at fbk.eu
Subject: Re: [GRASS-GUI] Re: [GRASSGUI] wxgrass wishes: have
1 GUI window instead of many
Date: Wed, 28 Nov 2007 10:24:04 +0000

> Trevor Wiens wrote:
> 
> > > I always raised my hand for having the GUI completely
> > > manageable from command line. When I started to work
> > > on wxgrass, I tried hard to have the map windows
> > > independent on the manager windows. Set of command
> line commands was provided, which where wrappers for
> > > raster and vector commands -- see
> > >
>
https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/scripts/#_trunk_grassaddons_gui_scripts_
> > >  for examples. I used temporary files for the
> > > communication, because of AFAIK, there are problems
> > > with sockets on non-unix platforms (correct me, if I'm
> > wrong). 
> > unix style sockets yes, but not TCP sockets which are
> > quite a robust cross-platform solution to achieve this
> result using Python.
> 
> The problem with TCP sockets is that you need to code some
> form of authentication mechanism. With a Unix-domain
> socket, you can just set the permissions to 0600 so that
> only the owner can connect to it.
> 

True, but given this is the only flexible cross-platform
solution, this is still the best option. I have a colleague
who had taken a Python course with Mark Lutz (author of
multiple Python books), who kindly contacted him on my
behalf in the early stages of my thinking on this process
and Mark strongly endorsed the concept of sockets as the
most flexible and appropriate Python solution to the
problem. 

In the short term, it wouldn't be all that onerous to write
a simple authentication mechanism to ensure that signals
were only accepted from the current machine and using a
session id to ensure that multiple running copies didn't
send messages at cross purposes. In the long term it places
the beginnings of a functional hook for remote use if one
chooses to build a more robust and flexible authentication
mechanism.

T

--
Trevor Wiens
twiens at interbaun.com