[Pywps-dev] hangout summary

Jonas Eberle jonas.eberle at gmx.de
Thu Jun 19 02:11:52 PDT 2014


Hi Jorge, 

thank you for your detailed response. 

> 1) You dont have to deal with workflow management and execution. While
> the workflow runs as a single WPS process you get update and extra
> information from the WPS status response.

The main part is the conversion from XML code to a PyWPS process. So the generated code have to handle the workflow, all inputs and outputs, conditions, loops, etc. 

> 2) You can assemble dynamically any pywps process using the pywps python
> classes, the code will look like a bunch of class-hacks together but
> will work.

Anna is using owslib to access WPS processes. With this we are open to include external WPS processes. 

> 3) We never talked about security, since you are modifying the process
> list and running code 'injected' by the client therefore you have a
> security problem.

As the generated python code is based on the XML workflow this "injected" code should be fine. Maybe we can define a parmeter in the config file wether to allow external processes or not to enhance the security. Storing the new process in the "processes" directory needs write access by the webserver, that's definitely a security issue we have to think about. Furthermore security handling when updating or deleting a workflow / WPS process is a critical issue. 

> 4) Personally I would prefer a sort of WPS-T module/classes/plugin
> inside PyWPS that would support process chain and run it, and not so
> much a single process going the work. This option would mean more work
> but a more structured approach, unfortunately it would be to much work
> for the scope of the SoC.
A WPS-T module would be the best solution. But for this project it is more important to get a good conversion from XML workflow code to a PyWPS process. This code can be transferred later on to a WPS-T handler. So using a process instead of writing a new WPS-T module is just an easier / temporary way. 

> 5) aside from "receiveXML" you could have some extra supporting
> Processes for example:

> "pauseProcess"
> "killProcess"
> "deleteProcess"

> I assume that the XML workflow will return a pure WPS process and than
> the user will start making a WPS call and therefore no need for
> "startProcess"
That's right. After successfull insertion the user can use normal WPS requests to start the workflow. 

Cheers, 
Jonas 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pywps-dev/attachments/20140619/68d32081/attachment.html>


More information about the pywps-dev mailing list