<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div>This approach is pretty to what the IPython developers implemented with their HTM5+JS interface to the IPython Kernel. (IPython Notebook) </div><div><br></div><div><div>As RPC interface, IPython is using pyzmq (based on zeromq).</div><div><br></div><div>IPython has a already a QtConsole with “inline plot” that can easily replace the Qgis python shell.</div><div>This will give us inline plot to implement the ,missed d.* capabilities of grass 5.* and 6.* </div><div>as well as direct call to grass commands (in IPython any system call can be performed using the prefix “!”)</div><div>and using the “!” prefix or the %%BASH magic we can call any grass module, if the GRASS envs are properly exported.</div><div><br></div><div>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, </div><div>and i found in this approach the only way to let me use GRASS in a productive way(now that tcltk is removed)</div><div><br></div><div>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 </div><div><br></div><div>I was planning to reuse part of this technologies for the WebGRASS interface, mixing IPython and PyWT.</div><div><br></div><div>I’m catching a fight right now, this video is almost “old” but shows how the widget interact API works :</div><div><br></div><div><a href="http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523">http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523</a></div><div><br></div><div> i like the RPC approach, and i guess we can reuse the ipython sw to implement this capabilities.</div><div><br></div><div>please apologize me if i went OFF topic ..</div><div><div><div><br></div><div>Massimo.</div><div><br></div><div><br></div><div>On Mar 27, 2014, at 11:17 AM, Sören Gebbert <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi Paolo,<br><br>2014-03-27 11:18 GMT+01:00 Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>>:<br><blockquote type="cite">Hi all.<br>I learned during dinner that GRASS7 RC1 is due very soon. This opens the<br>issue of its functioning in QGIS. IMHO:<br><br>* the qgis-grass-plugin might stop working (this has to be tested)<br></blockquote><br>Yes, it will stop working, since the API in GRASS7 has changed (Raster<br>API functions have now "Rast_" as prefix). Besides of that must the<br>cmake files be modified to detect GRASS7.<br><br><blockquote type="cite">* some of the module options will be different<br>* new modules will not be available in QGIS.<br></blockquote><br>Yes, but this shouldn't be a problem if the module interface<br>description created by the GRASS modules itself was used to generate<br>the module interface in QGIS. New and modified modules will not work<br>if the interfaces are handcrafted.<br><br><blockquote type="cite">I think we can deal with this in several ways:<br><br>* dropping the plugin, and concentrate the work on Processing<br></blockquote><br>That is IMHO not a good idea. I think to provide the full<br>functionality of GRASS7 to QGIS user, this plugin should be maintained<br>and updated to support the new GRASS7 API. Handling and processing of<br>massive datasets, especially time series, is only meaningful if GRASS<br>is used as data storage as well. The processing interface will add<br>massively overhead in data processing. The temporary location/mapset<br>creation approach is not well suited to process massive data, even<br>though r.external and v.external are used to link external data<br>temporary into GRASS.<br><br><blockquote type="cite">* upgrading both the plugin and Processing.<br></blockquote><br>Yes, that's the way to go.<br><br><blockquote type="cite"><br>In the first case, we have two major issues:<br><br>* upgrading Processing GRASS modules<br>* changing the current Processing behaviour, avoiding the import-export<br>phase when piping consecutive GRASS commands; this makes GRASS modules<br>slower than the equivalent commands of other backends.<br><br>While the first issue can be solved easily by a couple of people in a<br>few days, the second one is more tricky, and requires hard coding skills.<br>In addition, we'll no longer be able to edit GRASS vectors directly.<br><br>In the second case, we'll have more work, and a not-so-nice duplication.<br><br>I would like to have an open discussion on this, avoiding things to just<br>happen, with the possible negative consequences.<br></blockquote><br>My suggestion would be:<br><br>Full integration of the GRASS7 into QGIS via C++ or Python plugin.<br>This includes the temporal GIS capabilities as well.<br>The existing plugin is a very good start point, lots its functionality<br>can be reused, especially the vector editing, grass shell and map<br>management.<br><br>But there is a major problem with the GRASS QGIS plugin: it links<br>directly to the grass libraries and calls plenty of functions that can<br>QGIS cause to crash in case of an error. We face the same problem in<br>GRASS with the vector editing tools. My solution would be to use a RPC<br>(Remote Procedure Call) interface to calls GRASS library functions in<br>a remote process using binary data for inter-process communication.<br><br>IMHO the best tool for this is apache thrift[1] which allows us to<br>implement a RPC interface in GRASS7 to the needed library functions.<br>IMHO the number of RPC functions is limited since only vector editing,<br>raster map rendering and some map/stds management functions are needed<br>for direct access, all other functionality is provided by GRASS<br>modules.<br><br>So the first step is to implement an RPC interface in GRASS7, that<br>supports C/C++, Java, Python and JavaScript on the client side out of<br>the box. This interface can be used by the GRASS GUI itself to<br>implement exit safe vector editing and it can be used by QGIS and<br>other nice GIS desktop systems to provide GRASS database access, fast<br>raster rendering and vector edit functionality.<br><br>The beauty of this approach is, that the client side (the QGIS plugin<br>for example) do not need to link against GRASS libraries, since it<br>will communicate via pipes or sockets with one or several persistent<br>GRASS7 processes, which can be restarted in case of a fatal error. The<br>client side do not need to be updated in case the GRASS7 API changes<br>again, only the server side which will be implemented in GRASS7 must<br>be updated.<br><br>Implementation effort In case of the QGIS plugin:<br>All direct GRASS dependencies and function calls must be removed and<br>replaced by the client RPC solution. Hence the provider classes needs<br>to be rewritten, the C++ plugin code itself needs to be modified to<br>support the new interface datatypes that are used for inter-process<br>communication. Access to the temporal GIS functionality must be<br>implemented to list space time datasets.<br><br><br>What do you think about this approach?<br><br>Best regards<br>Soeren<br><br>[1]<span class="Apple-converted-space"> </span><a href="https://thrift.apache.org/">https://thrift.apache.org/</a><br><br><blockquote type="cite"><br>All the best.<br>--<br>Paolo Cavallini -<span class="Apple-converted-space"> </span><a href="http://www.faunalia.eu/">www.faunalia.eu</a><br>QGIS & PostGIS courses:<span class="Apple-converted-space"> </span><a href="http://www.faunalia.eu/training.html">http://www.faunalia.eu/training.html</a><br>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></blockquote>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></blockquote></div><br></div></div></body></html>