Hi, This approach is pretty to what the IPython developers implemented with their HTM5+JS interface to the IPython Kernel. (IPython Notebook)
As RPC interface, IPython is using pyzmq (based on zeromq). IPython has a already a QtConsole with “inline plot” that can easily replace the Qgis python shell. This will give us inline plot to implement the ,missed d.* capabilities of grass 5.* and 6.* as well as direct call to grass commands (in IPython any system call can be performed using the prefix “!”) and using the “!” prefix or the %%BASH magic we can call any grass module, if the GRASS envs are properly exported. I’m on a mac osx 64 bit, is almost 3 years i can not use grass GUI because of the WxPython interface that doesn’t support 64 bit on osx, and i found in this approach the only way to let me use GRASS in a productive way(now that tcltk is removed) Recent development in IPYthon enabled the ability to build complex widget based on query or othe r JS libs thanks to the “interact-widget” API I was planning to reuse part of this technologies for the WebGRASS interface, mixing IPython and PyWT. I’m catching a fight right now, this video is almost “old” but shows how the widget interact API works : http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523 i like the RPC approach, and i guess we can reuse the ipython sw to implement this capabilities. please apologize me if i went OFF topic .. Massimo. On Mar 27, 2014, at 11:17 AM, Sören Gebbert <soerengebb...@googlemail.com> wrote: > Hi Paolo, > > 2014-03-27 11:18 GMT+01:00 Paolo Cavallini <cavall...@faunalia.it>: >> 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) > > Yes, it will stop working, since the API in GRASS7 has changed (Raster > API functions have now "Rast_" as prefix). Besides of that must the > cmake files be modified to detect GRASS7. > >> * some of the module options will be different >> * new modules will not be available in QGIS. > > Yes, but this shouldn't be a problem if the module interface > description created by the GRASS modules itself was used to generate > the module interface in QGIS. New and modified modules will not work > if the interfaces are handcrafted. > >> I think we can deal with this in several ways: >> >> * dropping the plugin, and concentrate the work on Processing > > That is IMHO not a good idea. I think to provide the full > functionality of GRASS7 to QGIS user, this plugin should be maintained > and updated to support the new GRASS7 API. Handling and processing of > massive datasets, especially time series, is only meaningful if GRASS > is used as data storage as well. The processing interface will add > massively overhead in data processing. The temporary location/mapset > creation approach is not well suited to process massive data, even > though r.external and v.external are used to link external data > temporary into GRASS. > >> * upgrading both the plugin and Processing. > > Yes, that's the way to go. > >> >> 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. > > My suggestion would be: > > Full integration of the GRASS7 into QGIS via C++ or Python plugin. > This includes the temporal GIS capabilities as well. > The existing plugin is a very good start point, lots its functionality > can be reused, especially the vector editing, grass shell and map > management. > > But there is a major problem with the GRASS QGIS plugin: it links > directly to the grass libraries and calls plenty of functions that can > QGIS cause to crash in case of an error. We face the same problem in > GRASS with the vector editing tools. My solution would be to use a RPC > (Remote Procedure Call) interface to calls GRASS library functions in > a remote process using binary data for inter-process communication. > > IMHO the best tool for this is apache thrift[1] which allows us to > implement a RPC interface in GRASS7 to the needed library functions. > IMHO the number of RPC functions is limited since only vector editing, > raster map rendering and some map/stds management functions are needed > for direct access, all other functionality is provided by GRASS > modules. > > So the first step is to implement an RPC interface in GRASS7, that > supports C/C++, Java, Python and JavaScript on the client side out of > the box. This interface can be used by the GRASS GUI itself to > implement exit safe vector editing and it can be used by QGIS and > other nice GIS desktop systems to provide GRASS database access, fast > raster rendering and vector edit functionality. > > The beauty of this approach is, that the client side (the QGIS plugin > for example) do not need to link against GRASS libraries, since it > will communicate via pipes or sockets with one or several persistent > GRASS7 processes, which can be restarted in case of a fatal error. The > client side do not need to be updated in case the GRASS7 API changes > again, only the server side which will be implemented in GRASS7 must > be updated. > > Implementation effort In case of the QGIS plugin: > All direct GRASS dependencies and function calls must be removed and > replaced by the client RPC solution. Hence the provider classes needs > to be rewritten, the C++ plugin code itself needs to be modified to > support the new interface datatypes that are used for inter-process > communication. Access to the temporal GIS functionality must be > implemented to list space time datasets. > > > What do you think about this approach? > > Best regards > Soeren > > [1] https://thrift.apache.org/ > >> >> All the best. >> -- >> Paolo Cavallini - www.faunalia.eu >> QGIS & PostGIS courses: http://www.faunalia.eu/training.html >> _______________________________________________ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev