[GRASS-dev] GRASS & QGIS: the future

[Sören Gebbert]

Hi Glynn,

> An RPC wrapper would move the execution of GRASS functions into a new
> process (i.e. a server). If the call generates a fatal error, the
> server dies, the client detects this and reports an error rather than
> a result.
>
> The main problem with this is that any error loses the entire state
> held on the server, e.g. any open maps no longer exist.

Exactly!

Hence the wrapper will not only do simple function wrapping, it will
also implement a higher level interface:

* map metadata read access as single client function will do on the
server side: open map; read metadata; close map; send data

* fast raster and vector map read access as single client function
will do on server side: open map; read requested map into memory based
on bounding box and render resolution; close map; send data

* vector editing: keep a single vector map in update state open in a
dedicated grass vector editing process. In case of a fatal error, this
map may be lost or corrupted. It is important that this process will
not be used for other purposes than single vector map editing.

* vector analysis functionality that need to keep vector maps open in
read only state for fast topological access. Information's about the
open vector maps (i. e. the position of the next line to be read) may
be lost in case the server process terminates.

* Same for raster map analysis


The client will detect if the server was terminated and will raise an
exception. In QGIS that will be the data provider classes.

The dedicated raster display module in QGIS is a nice starting point
to implement a
RPC function that will read a raster map as RGB color array based on
extent and resolution information into a byte array that
will be send via thrift (using thrift binary protocol) to the client.

The RPC interface should only support meaningful functions to be used
in a GUI, that's its only purpose.
It should not be used to implement processing algorithms or GRASS modules.
But it will in addition provide capabilities to use several processes
to read different chunks of the same map in the GUI,
hence parallel read only map access. This can be nicely done using a
pool of GRASS server processes.

> Using setjmp/longjmp would be more useful, but it would require some
> effort to add clean-up code to functions so that core data structures
> aren't left in an inconsistent state.

There are plenty of functions using global variables in GRASS. Also,
persistent applications
may change the location and therefore the projection several times on
run-time. Are the GRASS libraries able to handle this correctly? The
suggested RPC server processes can be restarted in this case.

Best regards
Soeren