[GRASS-dev] GSoC 2014: GRAS GIS Web UI

[epi]

Stefan, I can try to answer here,


On Mar 7, 2014, at 2:25 AM, Blumentrath, Stefan <Stefan.Blumentrath at nina.no> wrote:

> Hi Rashad and Vaclav,
>  
> As mentioned, I really like the idea of a web-gui. Yet, at the end it will compete with VNC / Cygwin-X (at least in our setting). And I am afraid if it does not offer the same (or at least comparable functionality) most of my colleagues will stick to the former solutions.
>  
> Things which would be high on my personal priority list would be:
> -          A commandline interface (and possibly also a python console) in order to be able to paste code


This part is satisfied by the IPython Notebook interface.

the ipython notebook App (is highly customizable) and offer what you are asking, 
see here for very basic example [1]  usage with grass. 
the user can have access to both ‘python grass interface’  as well as ‘standard grass command line’ and any other tool is available on the user $PATH 
(just add the “!” prefix at each command, or "%%bash” on top of each cell ) 

Note that the IPython notebook is in active development and tons of new feature are coming out soon with the 2.0 release that implement api for complex widget (python<—>Js) to interact with the IPython kernel using JS widgets.
.. read below about security.

> -          Handling of user logins for accessing other ressources e.g in the home directory


WT has it’s auth framework for a basic login, so sure this is possible to implement and the web framework is here to support us, but keep in mind that this is a GSOC project with limited resources so i don’t think we are going to implement an full “user workspace” with filesystem navigation and feature like save/load workspace etc
(it is possible of course but it will require some work, means you’ll have to wait)


>  
> Another interesting question would be probably how users can get results to their local machines, both regarding map data (e.g. r.out.gdal) and text output (e.g. from r.stats)… Is there a chance for fetching output through the web-gui or would users have to connect to the server e.g. using FTP or fileshares e.g. in a company network?


the adoption of an IPython notebook as shell will provide a server app with “limited” file system navigation 
and ability to download file. 

# note: This could also be done irrespective of IPython

I personally use the apache web directory to download my products.

r.out.gdal … … output=/var/www/username/output

where “/var/www/username/output” is reader from a configurable option for each user


>  
> But of course, a research company network is only one use-case for a web-gui for GRASS…
> Maybe you ask on the user-list how other users would like to use a web-gui? That could help identifying priorities in the development process (e.g. regarding the possible data-license or security problems).

The main security risk as highlighted by Glynn is in enabling the shell access  trough the web, and that’s my concern too.
  
A resonable option can be to enabled/disabled shell avaibility based on a configurable option 
and IMHO such feature should be enabled only to a sub-set of trusted users.

In Rstudio the multiuser interface is based on PAM auth method and each user has his own ‘home’  server side 
Means that each user is a unix user on that machine. (also here the user as full access on its home, so this kind of approach is dedicated to trusted users only .. is not intended to be a web app available for anyone on the web .. will not be a forum or wikipedia but of course is intended to be an app for working group of trusted people) (there are exceptions**)

In IPython the dev team will work on this direction in the next release 3.0. (work will strut in july after release the 2.0)

An other extra layer of security can be to have the “shell feature” (that means IPython notebook) from inside a chroot jail on the a host machine. 

My thought is that enabling the shell will be a cool addition but it is an hard/hot topic and deserve some discussion here.

For a GSOC idea already have most of all the gui feature available in a web app (without shell access) will end in a great and useful app.

Of course the design of the app will take into the account the possibility to add shell access, but we can think about its implementation in a late stage of the project.
The answer to that will come along the line following the future development of the IPython notebook multiuser interface.


**There is people (see here [2]  [3] [4] ) that has already working example on how to “jail” in a sandbox the ipython environment perhaps they can be useful source for ideas on how to implement this in a safe way.

[1] http://nbviewer.ipython.org/gist/epifanio/9409749

[2] http://www.python.org/  (there is an interactive shell based on ipython)
 
[3] https://cloud.sagemath.com/

[4] https://github.com/liyanage/ipython-notebook/wiki



as Vaclav suggestion (thanks to start the wiki page about that!), should we put  all the info on the wiki and extend the discussion to the user list as well ?


Massimo.


>  
> Best regards,
> Stefan
>  
>  
> From: Rashad M [mailto:mohammedrashadkm at gmail.com] 
> Sent: 6. mars 2014 21:32
> To: Vaclav Petras
> Cc: epi; Blumentrath, Stefan; grass-dev at lists.osgeo.org
> Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
>  
> Hi Vaclav,
>  
> I think that the web UI has to be based on the GRASS library and has to not depend on WxWidgets or any other Desktop gui toolkit like JavaFX. g.parser is enough to describe the modules interface and can be used to automatize the build of the module form for any modules. I got your idea of running the same on desktop, web, embedded platforms which is theoretically possible but the run into deadend from time to timeas they are started for desktop application. 
>  
> Qt has webkit interface, like you said for JavaFX ( i dont know much about the java). The philosophy of a desktop gui toolkit is entirely different from a web application ui. For example message passing or Qt signals/slots can't be used directly. Infact these people have a different implementation and interpretation of signal and slot when used in web. 
> It is because people had written QtWebkit, Broadway with the same idea in mind as you, now it possible to run these. But they can't used in a many of application sucessfully. For example, rendering a map on Qt and web browser cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for vector data for this reason. We can't use the everywhere used GDAL for web easily. Boradway or JavaFX and other friends is very much feasible for some projects but not all. 
>  
> For this idea i envision the web gui app based on :
> - mapset-location wizard
> - map canvas 
> - toolbar with:
>   pan, query
>   zoom in/out/bbox to-layer to-region
> - menu bar with same layout of grass desktop
>  
> Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal with your data. of course you can. None will fix the data used by web application and you could just give a try without evening compiling etc.. (these are some view on webgrass we both saying). 
>  
> Regarding the reuse of code. I am planning to use python bindings for wt and core classes will be reused. for parsing description file and the instead of sending boradway or JavaFX etc.. I will use directly a jquery dialog, html button, text and will have direct access to js code such that if i need to render a grass vector i could do it in openlayers or using wt itself to read the grass vector directly using gdal and draw polygons on a HTML5Canvas, SVG, etc..  I could use render module of grass ui to render a ppm or use pygrass numpy to read grass and render as before.
>  
> For  Sharing data is one thing i need to think about and having a "shared location" like share folders could be explored. 
>  
> For GRASS 3D. its not possible to use opengl on web. you must use webgl. and I dont think the previous GTK broadway could use opengl. 
>  
> Also GRASS is famous for large data processing and i was exploring that too.  So the webUI must be behave differently when dealing with large data and should allow you to queue any process. Just thinking for now. 
>  
> And the whole idea of having webgrass will help users and developers as stefan was mentioning to run them on university or a company network without caring of operating system and Wt support Windows, Linux, OS X among other embedded platforms.
>  
> The demo video of android was from 2012 and since then Wt improved Android support. In 2012 there was not automated apk. But when I checked in 2013 wt build system if configured for android will generate an apk for your application.
>  
> I would ask you to think webUI as a wrapper like python, java etc.. You can have two gui for GRASS GIS. Remember about grass6.3 and earlier version which uses tcl/tk and was not used now because lack of support and or functionality and I am never saying Wxwidgets is not lacking a functionality for a desktop platform but on web perspective i think it is. Am I right?
>  
> 
> On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>  
> On Thu, Mar 6, 2014 at 1:38 PM, epi <massimodisasha at gmail.com> wrote:
> At the moment i’m having so much fun with IPython Notebook
> that is my actually my grass interface ... in this idea i can see a little room for it too :)
>  
> IPython Notebook would be the clear choice of Python command console for a web GUI written from scratch. Similarly, OpenLayers or Leaflet could become a web GRASS GUI map display. The downside of things such as GTK+ Broadway is that these solutions are simply not available. Although they can be always used inside some web view. With this we are getting to the other option I was mentioning: web-based GUI used in a web view(s) on desktop. This would allow us to use all highly interactive Java Script visualization libraries on desktop.
>  
> http://wxpython.org/Phoenix/docs/html/html2.WebView.html
> 
> 
>  
> --
> Regards,
>    Rashad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140307/d753a824/attachment-0001.html>