[Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines

[G. Allegri]

>
> With QGIS, a service can use any function in core/analysis library.
> Additionally, Python webservices might directly use qgis bindings and
> python
> plugin functionality by importing the relevant classes (correct me if I'm
> wrong).
> Is there a use-case where it is necessary to manage the functionality by a
> central server instance?
>

I don't know what exactly the python bindings could add to the Qgis
Mapserver. I feel that we can already build a python server app using the
already available Qgis bindings...
Well, things can be done in several (infinte?) different ways. Anyone can
build its own service and deploy it, even using the Python Qgis bindings,
avoiding the fcgi interface. I was thinking to a single gateway for the
following reasons (which probably are strictly subjective):

 - avoid forcing the use of Python to deploy the services, and let
users/developers use a common fcgi interface.
As it is for Mapserver: you can use mapscripting, but you can call MS
directly even for vendor specific requests (e.g. html templates). MS
incorporates everything in a monolythic server, making it difficult to
develop and deploy third-party features.

 - have a single "register", as it is in Geoserver. With Geoserver every
extension registers itself, and expose functionalities and the kind of
requests (key/value pairs) it can manage.

Anyway, the hypothesis 0 is to let eveyone build its own fcgi server, or
python gateway ;)

giovanni



>
> Regards,
> Marco
>
> Am Freitag, 21. Oktober 2011, 12.07:21 schrieb G. Allegri:
> > 2011/10/21 Marco Hugentobler <marco.hugentobler at sourcepole.ch>
> >
> > > Hi all
> > >
> > > It would be great to have a mapscript equivalent for QGIS server, so
> the
> > > possibility to modify the request before it arrives at QgsWMSServer
> > > class.
> > >
> > > > GeoServer will provide WMS, WCS and WFS automatically for the data.
> > > > That could also QGIS server do by default. But with the gateway
> > > > interface QGIS could provide some custom services, maybe working
> > > > properly only with some specific data.
> > >
> > > What would be the benefit of the gateway interface class compared to
> > > other services using FastCGI? E.g. if one want to build a WFS/WPS
> > > service with QGIS,
> > > the obvious solution would be to create qgis_wps_serv.fcgi or similar.
> Is
> > > it
> > > the idea to have shared service functionality on service level which is
> > > specific to QGIS services?
> >
> > I think that the main benefit would be having a single interface to
> manage,
> > both on the side of fcgi configurations (eg Apache) and global, server,
> > configurations.
> > I imagine that one could expose some services depending on the overall
> > configuration, or per user, or per domain, etc.
> > Geoserver let services share functionalities, being "beans" managed by
> the
> > server context available to any service. Anyway this could be a future
> > feature (I suppose it would take not a small time to be designed and
> > implemented), but having a single gateway opens to this possibility too.
> >
> > giovanni
> >
> > > Regards,
> > > Marco
> > >
> > > Am Donnerstag, 20. Oktober 2011, 22.54:30 schrieb Martin Dobias:
> > > > On Thu, Oct 20, 2011 at 5:40 PM, G. Allegri <giohappy at gmail.com>
> wrote:
> > > > > 2011/10/20 Martin Dobias <wonder.sk at gmail.com>
> > > > >
> > > > >> On Thu, Oct 20, 2011 at 4:00 PM, G. Allegri <giohappy at gmail.com>
> > >
> > > wrote:
> > > > >> > I imagine a plugin system, similar to Qgis Desktop, where every
> > > > >> > service is
> > > > >> > discovered/registered if available in certain library paths.
> > > > >>
> > > > >> I am not sure if such implicit (automatic) registration would be
> > > > >> good. Imagine that you have several web services. You would like
> to
> > > > >> run a public WMS server and also another bunch of services for a
> > > > >> limited group of users. Having all the services available in both
> > > > >> instances would not be very good - e.g. with a WMS server you may
> > > > >> automatically provide WPS server.
> > > > >
> > > > > Looking at similar architectures, Geoserver seems to work this way,
> > > > > leaving to a security/configuration layer to enable and control the
> > > > > availability of the extensions.
> > > > > Anyway, we can avoid an automatic discovering, and control their
> > >
> > > exposure
> > >
> > > > > through a configuration system (eg a simple configurations file).
> > > >
> > > > GeoServer will provide WMS, WCS and WFS automatically for the data.
> > > > That could also QGIS server do by default. But with the gateway
> > > > interface QGIS could provide some custom services, maybe working
> > > > properly only with some specific data.
> > > >
> > > > Martin
> > > > _______________________________________________
> > > > Qgis-developer mailing list
> > > > Qgis-developer at lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > >
> > > --
> > > Dr. Marco Hugentobler
> > > Sourcepole -  Linux & Open Source Solutions
> > > Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> > > marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> > > Technical Advisor QGIS Project Steering Committee
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20111022/afdbc778/attachment-0001.html