Hi Giovanni and Radim On Wed, Oct 19, 2011 at 12:24 PM, G. Allegri <gioha...@gmail.com> wrote: > I was thinking to both the ways: > - expose geoprocessing directly through QGIS MS (either C++ plugins or > Python plugins) > - provide a Python mapscripting for QGIS MS (as you're saying) > I think the two ways are complementary. > The latter would let you "control" QGIS MS, and proxy requests, exactly the > same as Mapserver/Mapscript. > The first one would let you also expose code written for QGis Desktop. For > example, you could expose the features provided by the Processing Framework > (OTB, SAGA, etc.), or the code inside QGis Analysis.
A nice low-level solution would be to introduce a new class to qgis_core library that would take care of fastcgi functionality (e.g. QgsFastCgiServer) and an abstract interface for web-based services (e.g. QgsFastCgiService) for communication between the fastcgi server and the concrete service. One or more services could be registered to the fastcgi server and it would redirect the request to the services. Our WMS server would be therefore become a service running on top of QgsFastCgiServer, the mapserver executable would just create fastcgi server instance, add WMS service and start the server. With QgsFastCgiServer developers could implement basically any functionality they want. A simple WPS service could be built on top of the processing framework. Or a service that first does some processing, then renders the map and returns it (this would be the MapScript equivalent, right?) To use python we would need python wrapper of the server and service classes, something that could be done very easily. The WMS service could be probably made extensible, too, but the number of possible use cases would be probably smaller in order to stay compatible with WMS standard. Regards Martin _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
