Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Rashad and Massimo, can you please summarize the basic ideas at: https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS ? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Vaclav, Sure. Will update the ideas page today. On Wed, Mar 12, 2014 at 3:45 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad and Massimo, can you please summarize the basic ideas at: https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS ? -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hamish wrote: And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. Memory limits can be enforced by setrlimit(), via the ulimit shell command or the pam_limits module. However, you can't set cumulative limits[1]. You can limit the memory usage of an invidivual process, and limit the total number of processes for a single user (UID), but you can't set a cumulative limit below the product of the maximum number of processes times the maximum memory per process. Disk usage can be restricted by using quotas or by creating a separate filesytem (e.g. on a loop device) for each account. CPU usage can be restricted on a per-process basis via setrlimit() etc. Again, there's no way to set a cumulative limit. Also, nice can be used to de-prioritise processes so that more important processes aren't pre-empted. [1] On Linux, control groups (cgroups) can be used to partition system resources. Virtual machines are another potential solution, albeit a rather heavy-weight one. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Stefan, about anonymous access, the app can use a demo location that is generated on the fly using cloning a template location. If i well remember, PyWPS does something like that. But you need to be limit the number of available instance running … (has to be a configurable option), to avoid a server overload. how may anonymous users can test the app at the same time is up to the capabilities of your server. Cheers, Massimo. On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi, Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the “trused-user” approach would be the most popular… In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression… Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time? Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of epi Sent: 9. mars 2014 15:28 To: Glynn Clements Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Glynn, I’aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The “web-shell” feature is obviously reserved to only “trusted users”. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- Glynn Clements gl...@gclements.plus.com ___ 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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Stefan, On Mon, Mar 10, 2014 at 7:00 AM, epi massimodisa...@gmail.com wrote: Hi Stefan, about anonymous access, the app can use a demo location that is generated on the fly using cloning a template location. If i well remember, PyWPS does something like that. But you need to be limit the number of available instance running ... (has to be a configurable option), to avoid a server overload. how may anonymous users can test the app at the same time is up to the capabilities of your server. This is more of a customization of webGRASS. WebGRASS UI is the web extestion to run grass modules. If you want to allow anonymous users or trusted users is a question of deployment. Some webmapping framework allows a demo users and the person who installs webgrass on their server be it on internet or else, he must know his users as any other typical web application. For example you can deploy your data on internet using web services and map viewer client like OpenLayers and allow anonymous users or setup a login and allow only verified users. Again the the login could use (OAuth, simple db login, manual verification, auto email verification etc.). This shouldn't be a part of web framework in my opinon. Rather web application allows such provision in a non coupled way. In case of webgrass we decide to have trusted login by default. Cheers, Massimo. On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi, Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the trused-user approach would be the most popular... In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression... Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time? Cheers Stefan *From:* grass-dev-boun...@lists.osgeo.org [ mailto:grass-dev-boun...@lists.osgeo.orggrass-dev-boun...@lists.osgeo.org ] *On Behalf Of *epi *Sent:* 9. mars 2014 15:28 *To:* Glynn Clements *Cc:* grass-dev@lists.osgeo.org *Subject:* Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Glynn, I'aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The web-shell feature is obviously reserved to only trusted users. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the input coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
epi wrote: I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the �input� coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the �input� coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:22 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 11:04 PM, epi massimodisa...@gmail.com wrote: Vaclav, Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. Develop the sanitizer on the web-ui code and do not touch the g.parser source code. The sanitizer code will following the guidelines found at the page [thanks] you pointed : “Complete Structure Members Table” but extending the restrictions to what Glynn suggested : size constraint, alphanumeric characters, maximum number of items in a list and more. this restriction will be true for the web-ui but not for the desktop gui hence the need to leave untouched the grass command line parser code. does this make sense for you ? Yes, it does. For example, if module accepts parameter of type string, parser checks nothing in this case. However, web UI (1) should have the information (obtained from `--interface-description` XML) that it is a string and restrict the string to 255 characters (just an example). That’s how we’d like to design the gui modules, using g.parser to generate the module descriptions and then use this information to generate the code to render each module. i Guess wx gui works this way. PyQt does something similar with .ui files generated in designer. In our case the .ui is the module description and is generated by g.parser. (1) Actually, both the web GUI and something which is behind it on server side should have this check. In GUI, you want to tell the user that the input is invalid before sending the data for processing but also once data are at the server they should be checked again for case that somebody is not using the GUI but just sending the data to server side of the application (in order to bypass the GUI check). The web development framework may (or may not) solve these two steps for you at once. I can see your idea of having the gui code to do a first check when the module is filled on the client and a second check server side when the instruction is received. thanks to share it. Essentially any command string received by the server will be parsed and checked for the validity of each entry (in regards of the module being executed) . This make perfectly sense to me. Massimo. Vaclav Massimo. On Mar 10, 2014, at 10:32 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 10:19 PM, epi massimodisa...@gmail.com wrote: Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead. (1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost. [1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html [2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the �input� coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- Glynn Clements gl...@gclements.plus.com ___ 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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
googling i found the ulimit should take care of memory usage : https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage http://ss64.com/bash/ulimit.html On Mar 11, 2014, at 1:20 AM, epi massimodisa...@gmail.com wrote: On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Glynn, I’aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The “web-shell” feature is obviously reserved to only “trusted users”. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- Glynn Clements gl...@gclements.plus.com ___ 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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi, Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the trused-user approach would be the most popular... In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression... Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time? Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of epi Sent: 9. mars 2014 15:28 To: Glynn Clements Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Glynn, I'aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The web-shell feature is obviously reserved to only trusted users. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the input coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.commailto:gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- Glynn Clements gl...@gclements.plus.commailto:gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.orgmailto: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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Rashad M wrote: I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. None of this is an issue for normal use, as exploiting GRASS modules doesn't gain a user any access which they don't already have. But for a web application, allowing a user to run GRASS modules with arbitrary inputs amounts to giving them shell access. You might even want to create an actual Unix account for each user, so that any failures regarding input sanitisation are contained. However, this would require something like suExec or servlets. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Vaclav Petras wrote: Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, Broadway is probably far too heavyweight. It's basically a remote desktop approach (the X server runs on the client, but you still have a persistent GUI application for each user running on the server). Also, it behaves like a desktop application which is exported to a web browser, not like a web application. The end result is almost identical to using a desktop application via ssh with X forwarding; if there's any advantage to Broadway, it's that it simplifies the connection setup. Basically, it's a question of thin client (Broadway, ssh -X, VNC, etc) versus thick client (web browser). Both have their pros and cons, but a thin-client solution isn't really worthy of a GSoC project IMHO (thin client approaches typically target an entire desktop environment rather than specific applications). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Glynn. On Fri, Mar 7, 2014 at 5:14 PM, Glynn Clements gl...@gclements.plus.comwrote: Rashad M wrote: I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. None of this is an issue for normal use, as exploiting GRASS modules doesn't gain a user any access which they don't already have. But for a web application, allowing a user to run GRASS modules with arbitrary inputs amounts to giving them shell access. Regarding shell accees we are thinking IPython. and massimo had experience in using with GRASS. We are exploring its integration with Wt You might even want to create an actual Unix account for each user, so that any failures regarding input sanitisation are contained. However, this would require something like suExec or servlets. I thought of having a user account setup and the shell on web ui won't allow to navigate around any folder -- Glynn Clements gl...@gclements.plus.com -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
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:mohammedrasha...@gmail.com] Sent: 6. mars 2014 21:32 To: Vaclav Petras Cc: epi; Blumentrath, Stefan; grass-dev@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 wenzesl...@gmail.com wrote: On Thu, Mar 6, 2014 at 1:38 PM, epi massimodisa...@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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Fri, Mar 7, 2014 at 12:23 PM, epi massimodisa...@gmail.com wrote: 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 ? My idea is that mailing list is for discussion while wiki is better for preserving results of the discussion and as a overview for the people not involved in the dicussion from the beginning. Speaking about https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS For the GSoC idea itself, it should be in the same form as other ideas here: https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS grass-user would be best for getting requirements, such as I want what ArcGIS Online is doing and finding out what does this actually means. And about the other things, I really cannot elaborate on this (no knowledge, no time) but when we are speaking about jails, virtual session or whatever for Wt-based and IPython-Notebook-based web GUI, wouldn't that be the same for Broadway-based GUI? I would guess that rollapp.com is doing something similar. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hello All, I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. [1] http://www.webtoolkit.eu/wt -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Rashad, On Thu, Mar 6, 2014 at 10:28 AM, Rashad M mohammedrasha...@gmail.comwrote: Hello All, I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. [1] http://www.webtoolkit.eu/wt FWIW, I like this idea and would like to see it developed. Do you have a prototype already? Thanks, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Margherita, I do have a proof of concept quite old now. No recent updates. But I hope GSoC will be able to change the current situation and move it upfront https://www.youtube.com/watch?v=B71DQiCw86o On Thu, Mar 6, 2014 at 3:17 PM, Margherita Di Leo dileomargher...@gmail.com wrote: Rashad, On Thu, Mar 6, 2014 at 10:28 AM, Rashad M mohammedrasha...@gmail.comwrote: Hello All, I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. [1] http://www.webtoolkit.eu/wt FWIW, I like this idea and would like to see it developed. Do you have a prototype already? Thanks, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com is using. Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). Fourth, the processing on server could be also invoked from a desktop GUI. This would require user to install the desktop GUI but the processing part would be placed on server. This is just another option. Fifth, the choice of the GUI framework is important. We don't want to tight this to some project which will not be here in few years. Wt has nice examples and your (Rashad's) experience is big plus. But there is many others such as Dabo and some of them might be better for us since they are using Python, so we could share some code with wxGUI. Results on mobile platforms must be evaluated, too. And finally, a sustainability of the new web GUI must be considered. What will happen after the GSoC? There already were several GRASS web interfaces starting with GRASSLinks in 1995 and also we have some web sites using GRASS in background but they are not general GRASS GUI (e.g. http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with the desktop GUI seems crucial and merging this to GRASS and developing other infrastructure, too. I don't want you to feel overwhelmed by all of these considerations but I was thinking about this topic for some time, so I collected some ideas and now is the time to share them. Vaclav PS: I just saw your video, congratulations, it looks good and responsive. Is the code somewhere online? On Thu, Mar 6, 2014 at 4:28 AM, Rashad M mohammedrasha...@gmail.com wrote: Hello All, I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. [1] http://www.webtoolkit.eu/wt -- Regards, Rashad ___ 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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com is using. I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget! When you write: WButton *button = new WButton(); Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do. Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind of data under NDA or so in public server right? And you cant access a data on server even when you render it on browser screen. That is what mapserver, Openlayers and other web map viewer are doing. Fourth, the processing on server could be also invoked from a desktop GUI. This would require user to install the desktop GUI but the processing part would be placed on server. This is just another option. I am not clear with this. Why do you need to invoke a desktop interface for running a webapp. I did had a the demo version running on server with no X server. Fifth, the choice of the GUI framework is important. We don't want to tight this to some project which will not be here in few years. Wt has nice examples and your (Rashad's) experience is big plus. But there is many others such as Dabo and some of them might be better for us since they are using Python, so we could share some code with wxGUI. Results on mobile platforms must be evaluated, too. There has been a python binding for Wt and myself and massmio had tried these successfully. The support for bindings are not much, I would say but I had a pretty much idea about how its generated which BTW is not using swig and SIP. Regarding mobile platforms I do had a working apk of another Wt application for which I got a recording on youtube[1] (offline android). [2] is the web version. The patch required for me was very minimal as Wt compiles clean on Android. [1] also used libgdal (Android). This one just renders a shapefile and style it without OpenLayers or its friends And finally, a sustainability of the new web GUI must be considered. What will happen after the GSoC? There already were several GRASS web interfaces starting with GRASSLinks in 1995 and also we have some web sites using GRASS in background but they are not general GRASS GUI (e.g. http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with the desktop GUI seems crucial and merging this to GRASS and developing other
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Rashad and Vaclav, If you allow me a user comment: The video looks very, very promoising. In our institution we are running GRASS on an Ubuntu Server which users access graphically either through either TightVNC or CYGWin-X. What I like about the Server solution is the work where your data is concept (even if server ressources may be smaller when shared by several users, compared to modern single user desktop PCs). I also perceive GRASS`s mapset concept as very useful for multi-user environment and data sharing (maybe except for the ownership check which hampers usage of mapsets by groups of people (I know there are workarounds (e.g. goup users as owners or overriding the ownership check in GRASS 7)). On the same Server we also have an RStudio-Server running which would be comparable to your webGRASS-solution. Our experience with RStudio Server is very positive, so I would appreciate such a solution for GRASS (though TightVNC and CYGWin-X are fine too)... The main advantage is (from my point of view) that users do not have to install additional software... Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad M Sent: 6. mars 2014 18:12 To: Vaclav Petras Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.commailto:wenzesl...@gmail.com wrote: Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.comhttp://rollapp.com is using. I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget! When you write: WButton *button = new WButton(); Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do. Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind of data under NDA or so in public server right? And you cant access a data on server even when you render it on browser screen. That is what mapserver, Openlayers and other web map viewer are doing. Fourth, the processing on server could be also invoked from a desktop GUI. This would require user to install the desktop GUI but the processing part would be placed on server. This is just another option. I am not clear with this. Why do you need to invoke a desktop interface for running a webapp. I did had a the demo version running on server with no X server. Fifth, the choice of the GUI framework is important
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Rashad, Vaclav, all that’s a great idea for a GSOC! and I’m willing to apply as student for it :) I’m familiar with the Web GRASS prototype as i was a beta-testing during its early development. and i have experience with grass and python development and and with WT and its python bindings. 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 :) Cheers, Massimo. On Mar 6, 2014, at 12:45 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Rashad and Vaclav, If you allow me a user comment: The video looks very, very promoising. In our institution we are running GRASS on an Ubuntu Server which users access graphically either through either TightVNC or CYGWin-X. What I like about the Server solution is the “work where your data is” concept (even if server ressources may be smaller when shared by several users, compared to modern single user desktop PCs). I also perceive GRASS`s mapset concept as very useful for multi-user environment and data sharing (maybe except for the ownership check which hampers usage of mapsets by groups of people (I know there are workarounds (e.g. goup users as owners or overriding the ownership check in GRASS 7)). On the same Server we also have an RStudio-Server running which would be comparable to your webGRASS-solution. Our experience with RStudio Server is very positive, so I would appreciate such a solution for GRASS (though TightVNC and CYGWin-X are fine too)… The main advantage is (from my point of view) that users do not have to install additional software… Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad M Sent: 6. mars 2014 18:12 To: Vaclav Petras Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com is using. I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget! When you write: WButton *button = new WButton(); Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do. Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Thu, Mar 6, 2014 at 12:12 PM, Rashad M mohammedrasha...@gmail.com wrote: Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad, ... First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. You need to use Python to really reuse the classes. And do also a large refactoring of wxGUI code to make them reusable (although some improvements were already made). How much you can reuse? How much you want to reuse? This is probably hard to answer, easier might be which functionality do we want in web GUI? Only modules and map visualization? Or also digitizers, animations, map swipe, ...? The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. This is what previously mentioned GTK+ Broadway is doing. I'm not sure how does this compare to Ulteo and to whatever rollapp.com is using. noVNC is VNC where client runs in web browser. The advantage of these is that you don't write any new GUI code. https://developer.gnome.org/gtk3/stable/gtk-broadway.html http://blogs.gnome.org/alexl/2012/12/27/broadway-multi-process-suppor/ http://kolyakosenko.wordpress.com/2013/07/18/wxwidgets-2-9-5/ https://www.youtube.com/watch?v=P6lzZpS5M4g http://en.wikipedia.org/wiki/Ulteo_Open_Virtual_Desktop http://www.ulteo.com/ http://kanaka.github.io/noVNC/ https://www.youtube.com/watch?v=ZiIxtoHa9bU (rollapp.com) Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind of data under NDA or so in public server right? And you cant access a data on server even when you render it on browser screen. That is what mapserver, Openlayers and other web map viewer are doing. I though that the goal is to have something like Google Docs but for GIS. Which could be provided by GRASS community but more importantly, everyone would be able to setup his or her own server. I'm not concern about license of data, in terms of security, I'm concern about users accidentally deleting each other data or somebody running some evil processes on my server. And in terms of usability, some data upload/download functions are needed, management, ideally also sharing and perhaps publishing through web services by forwarding then to some map server. On Thu, Mar 6, 2014 at 12:12 PM, Rashad M mohammedrasha...@gmail.com wrote: Fifth, the choice of the GUI framework is important. We don't want to tight this to some project which will not be here in few years. Wt has nice examples and your (Rashad's) experience is big plus. But there is many others such as Dabo and some of them might be better for us since they are using Python, so we could share some code with wxGUI. Results on mobile platforms must be evaluated, too. There has been a python binding for Wt and myself and massmio had tried these successfully. The support for bindings are not much, I would say but I had a pretty much idea about how its generated which BTW is not using swig and SIP. Regarding mobile platforms I do had a working apk of another Wt application for which I got a recording on youtube[1] (offline android). [2] is the web version. The patch required for me was very minimal as Wt compiles clean on Android. [1] also used libgdal (Android). This one just renders a shapefile and style it without OpenLayers or its friends How much code are these applications? I somewhere accessible? How much development was in Wt since than? Some improvements, e.g. for Android? And finally, a sustainability of the new web GUI must be considered. What will happen after the GSoC? There already were several GRASS web interfaces starting with GRASSLinks in 1995 and also we have some web sites using GRASS in background but they are not general GRASS GUI (e.g. http://www.gapserve.ncsu.edu/segap/segap/). Minimizing
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Stefan. On Thu, Mar 6, 2014 at 12:45 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Rashad and Vaclav, If you allow me a user comment: User comments are not only allowed but they are needed. The video looks very, very promoising. In our institution we are running GRASS on an Ubuntu Server which users access graphically either through either TightVNC or CYGWin-X. ssh -X, VNC etc. are of course always here, so the question is home much more we will get from other solutions. What I like about the Server solution is the “work where your data is” concept (even if server ressources may be smaller when shared by several users, compared to modern single user desktop PCs). So, it seems that you want the full fully-featured GUI, not just some basic one. I also perceive GRASS`s mapset concept as very useful for multi-user environment and data sharing (maybe except for the ownership check which hampers usage of mapsets by groups of people (I know there are workarounds (e.g. goup users as owners or overriding the ownership check in GRASS 7)). This is what I was mentioning in other email. There could be different requirements on data management, especially sharing, in the online environment. On the same Server we also have an RStudio-Server running which would be comparable to your webGRASS-solution. Our experience with RStudio Server is very positive, so I would appreciate such a solution for GRASS (though TightVNC and CYGWin-X are fine too)… From quick check RSStudio is written in Java. E.g. the new Java GUI framework JavaFX allows to create desktop and web (probably client-server) application at once. Unfortunately, nor wxPython/wxWidgets or Qt (or its Python friends) does not allow this by themselves. JavaFX is not really an option for use, however the concept is what I would like to have. The GUI with the same look and (I believe) the same implementation on all desktops and also on web. https://www.rstudio.com/ide/screenshots/ (first four screenshots) The main advantage is (from my point of view) that users do not have to install additional software… So, web-based solution is necessary for that. Which e.g. kills my suggestion of wxGUI executing commands on server. Thanks for your input, if you have more, please do. Vaclav Cheers Stefan *From:* grass-dev-boun...@lists.osgeo.org [mailto: grass-dev-boun...@lists.osgeo.org] *On Behalf Of *Rashad M *Sent:* 6. mars 2014 18:12 *To:* Vaclav Petras *Cc:* grass-dev@lists.osgeo.org *Subject:* Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com is using. I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget! When you write: WButton *button = new WButton(); Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do. Third, the GUI is not the only part. The GUI is supposed to be a part
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Thu, Mar 6, 2014 at 1:38 PM, epi massimodisa...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
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 wenzesl...@gmail.com wrote: On Thu, Mar 6, 2014 at 1:38 PM, epi massimodisa...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Rashad, please basic description of your idea to https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS I also created a page to have ideas mentioned here stored in systematic way: https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS I will have limited possibilities to work on it in next days, so feel edit or put some facts directly there. I hope that others will also join this discussion which goes far behind the GSoC. Vaclav On Thu, Mar 6, 2014 at 3:32 PM, Rashad M mohammedrasha...@gmail.com wrote: 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 wenzesl...@gmail.comwrote: On Thu, Mar 6, 2014 at 1:38 PM, epi massimodisa...@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
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
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 - Handling of user logins for accessing other ressources e.g in the home directory 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? 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). Best regards, Stefan From: Rashad M [mailto:mohammedrasha...@gmail.com] Sent: 6. mars 2014 21:32 To: Vaclav Petras Cc: epi; Blumentrath, Stefan; grass-dev@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
