[Qgis-developer] [GRASS-dev] GRASS & QGIS: the future

[Sören Gebbert]

Hi Radim,
IMHO we GRASS developers are  too stubborn to change the design of
GRASS GIS to work as library with persistent applications. This would
require rewriting plenty of core functionality and modification of all
C-modules. But there is a solution for persistent applications, called
Remote Procedure Call (RPC), more below.

2014-04-18 11:31 GMT+02:00 Radim Blazek <radim.blazek at gmail.com>:
> I have upgraded  the vector provider to GRASS 7, layers may be added
> by drag from browser. The raster and the plugin are disabled. Be
> careful about multiple versions on the same system
> (LD_LIBRARY_PATH..., check with ldd if does not work).
>
> Unfortunately GRASS 7 moved ahead towards its aim "to make life harder
> for anyone trying to use the GRASS libraries" [1]. Basically more and
> more low level functions are calling exit() instead of returning error
> code if something failed. As I am not willing to implement GRASS
> module call for each simple function, we have to think again about
> hacks we can use:
>
> 1) add a requirement that GRASS 7 used with QGIS must be compiled with
> -fexceptions
>
> 2) add a requirement that a patch (it is a single line comment in
> fact) must be applied to GRASS 7 to make it usable with QGIS
>
> 3) use setjmp()/longjmp()
>
> 4) let QGIS crash whenever GRASS lib function fails

I fear that none of these suggestions are good working solutions,
since in case a fatal error or a segfault occurs nothing (no
exception, no setjmp) will prevent QGIS from crashing. So i would like
to suggest the following:

5.) Using a RPC interface for map metadata, vector and raster map
access. Hence one or several GRASS "server" processes provide an RPC
interface to access GRASS library functions that are needed in a
persistent application. Most important is the vector editing, vector
reading/writing, database access, raster reading and map metadata
support. Everything else can be done using modules. Hence the RPC
interface will support only a limited subset of the GRASS library
functions. This RPC interface should only be used in the GRASS
provider classes, the GRASS plugin itself can be written in C++ or
Python.

This approach will decouple GRASS from QGIS, since all communication
is done via Inter Process Communication (IPC) using pipes or sockets.
There is no need anymore to catch a fatal error or to link GRASS
libraries directly to QGIS. The GRASS plugin can be implemented GRASS
version independently and so the GRASS data provider, since they will
not use GRASS functions directly only the RPC interface. The RPC
implementation on the side of GRASS will provide a consistent
interface that will not change in case the underlying GRASS API
changes.

I strongly suggest to use an existing RPC framework to implement fast
binary data exchange and the IPC. My favorite is apache thrift[1],
since it supports plenty of programming languages (C/C++, Python,
Java, JavaScript, ...) and provides operating system independent
client and server functionality. It supports exceptions on client side
that can be emitted in case a GRASS server process died because of a
fatal error, SIGINT or segfault.

I am absolutely willing to implement the RPC server side in GRASS
using thrift and C++, providing plenty of Python unit tests that show
howto use it on the client side. We just need to decide what kind of
GRASS library functionality is needed as RPC interface and what can be
done in QGIS with C++/Python directly (gisrc creation, GRASS
environmental variable settings, ...) or using GRASS modules
(g.region, g.gisenv, ...).

[1] https://thrift.apache.org/


Best regards
Soeren

>
> Radim
>
> [1]https://trac.osgeo.org/grass/ticket/869#comment:1
>
> On Thu, Mar 27, 2014 at 11:18 AM, Paolo Cavallini <cavallini at faunalia.it> wrote:
>> Hi all.
>> I learned during dinner that GRASS7 RC1 is due very soon. This opens the
>> issue of its functioning in QGIS. IMHO:
>>
>> * the qgis-grass-plugin might stop working (this has to be tested)
>> * some of the module options will be different
>> * new modules will not be available in QGIS.
>>
>> I think we can deal with this in several ways:
>>
>> * dropping the plugin, and concentrate the work on Processing
>> * upgrading both the plugin and Processing.
>>
>> In the first case, we have two major issues:
>>
>> * upgrading Processing GRASS modules
>> * changing the current Processing behaviour, avoiding the import-export
>> phase when piping consecutive GRASS commands; this makes GRASS modules
>> slower than the equivalent commands of other backends.
>>
>> While the first issue can be solved easily by a couple of people in a
>> few days, the second one is more tricky, and requires hard coding skills.
>> In addition, we'll no longer be able to edit GRASS vectors directly.
>>
>> In the second case, we'll have more work, and a not-so-nice duplication.
>>
>> I would like to have an open discussion on this, avoiding things to just
>> happen, with the possible negative consequences.
>>
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer