[GRASS-dev] GPL GRASS, CSP and distributed systems

[tlaronde at polynum.com]

Hello,

Since KerGIS and myself are part of GPL GRASS IRC mockery:

------
 00:49:20  	jachym:  	 and say "hallo" to kergis developers, if you
 meet them
 00:49:22 	jachym: 	;- )

 00:50:21 	huhabla: 	jachym: the kergis dev like the old 4.1 GRASS
 gis, not new technology

  06:36:11  	:  	* huhabla just tried kergis ... wow what a waste of
  development time ... what a pity
------

I will give you some more fun. "What this retarded developer is losing
his time about?": CSP and distributed systems.

Because still aiming to understand the "old technology", I stumbled upon
an old feature of GRASS that matches the principles of the most
advanced, simple distributed system: Plan 9. You know, this thing made
by the creators of Unix, the Bell Labs, that run from handhelds to Blue
Gene. Curiously enough, KerGIS/GRASS has to run from handhelds (to
gather data on the field) to mainframe---to do the huge computations.

One of the principle underneath the distributed system, is to be able to
dispatch processing on different machines. An analyze of the needs also
leads to the conclusion that the user interface shall be disconnected
from the heavy processing, that is that handling the user interface is a
different task than computing the data. A graphical interface mainly
allows to select graphically commands to process data.

With the current windowing systems---X11 for example---using a toolkit
for the menu handling does _not_ disconnect the user handling---remember
the consequences of polling the mouse...---from the processing of the
data, since the menu handling is done on the client side, leading to
heavy network loads (to the server) and consuming a lot of processing
power on the client (CPU) with the problematic of blocking processes
(waiting for input, or freezing the interface since the system is doing
an heavy computation).

Curiously enough, the "old GRASS technology", sending graphical request
to a communication channel (a fifo, a socket) is the first step to allow
this and can be seen as a way to implement CSP (since the problem is
that you have to share the data---a vector file you are editing for
example).

Furthermore, once you understand that even the curses interface is just
a peculiar case of a 2D interface (cli is line oriented; curses is plan,
screen oriented), one can start to wonder if there could be such a thing
as a 2D interface description that will be converted in whatever 2D
interface system is available (one menu description for a program; the
interpreter launched by d.mon building it depending on the interface
defined in the gisenv; and the ability then to customize this text
description for local use).

The answer is: this already exists to some extend. Plan9/Inferno uses,
in Limbo, tk for the description; and tk is such a description. Public 
Domain Curses allows to link a curses interface to
an X11 "interpretation" transforming a curses interface into an X11
application (meaning that KerGIS can be already transformed with an
X11 look with little work---but this is not the aim). Etc.

It was just to let you have other subjects to bash my, I admit it,
lonely efforts. I must simply be the less gifted one that plagues every
family. The black sheep so erroneous that it has the colour of a wolf.

Since it is the end of the week and the beginning of the holidays
period, some refreshing jokes were needed. You have.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C