<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">With QGIS, a service can use any function in core/analysis library.</div>
Additionally, Python webservices might directly use qgis bindings and python<br>
plugin functionality by importing the relevant classes (correct me if I'm<br>
wrong).<br>
Is there a use-case where it is necessary to manage the functionality by a<br>
central server instance?<br></blockquote><div><br></div><div>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...</div>
<div>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):</div>
<div><br></div><div> - avoid forcing the use of Python to deploy the services, and let users/developers use a common fcgi interface. </div><div>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.</div>
<div><br></div><div> - 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.</div>
<div><br></div><div>Anyway, the hypothesis 0 is to let eveyone build its own fcgi server, or python gateway ;)</div><div><br></div><div>giovanni</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br>
Marco<br>
<br>
Am Freitag, 21. Oktober 2011, 12.07:21 schrieb G. Allegri:<br>
<div><div></div><div class="h5">> 2011/10/21 Marco Hugentobler <<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>><br>
><br>
> > Hi all<br>
> ><br>
> > It would be great to have a mapscript equivalent for QGIS server, so the<br>
> > possibility to modify the request before it arrives at QgsWMSServer<br>
> > class.<br>
> ><br>
> > > GeoServer will provide WMS, WCS and WFS automatically for the data.<br>
> > > That could also QGIS server do by default. But with the gateway<br>
> > > interface QGIS could provide some custom services, maybe working<br>
> > > properly only with some specific data.<br>
> ><br>
> > What would be the benefit of the gateway interface class compared to<br>
> > other services using FastCGI? E.g. if one want to build a WFS/WPS<br>
> > service with QGIS,<br>
> > the obvious solution would be to create qgis_wps_serv.fcgi or similar. Is<br>
> > it<br>
> > the idea to have shared service functionality on service level which is<br>
> > specific to QGIS services?<br>
><br>
> I think that the main benefit would be having a single interface to manage,<br>
> both on the side of fcgi configurations (eg Apache) and global, server,<br>
> configurations.<br>
> I imagine that one could expose some services depending on the overall<br>
> configuration, or per user, or per domain, etc.<br>
> Geoserver let services share functionalities, being "beans" managed by the<br>
> server context available to any service. Anyway this could be a future<br>
> feature (I suppose it would take not a small time to be designed and<br>
> implemented), but having a single gateway opens to this possibility too.<br>
><br>
> giovanni<br>
><br>
> > Regards,<br>
> > Marco<br>
> ><br>
> > Am Donnerstag, 20. Oktober 2011, 22.54:30 schrieb Martin Dobias:<br>
> > > On Thu, Oct 20, 2011 at 5:40 PM, G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>> wrote:<br>
> > > > 2011/10/20 Martin Dobias <<a href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a>><br>
> > > ><br>
> > > >> On Thu, Oct 20, 2011 at 4:00 PM, G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>><br>
> ><br>
> > wrote:<br>
> > > >> > I imagine a plugin system, similar to Qgis Desktop, where every<br>
> > > >> > service is<br>
> > > >> > discovered/registered if available in certain library paths.<br>
> > > >><br>
> > > >> I am not sure if such implicit (automatic) registration would be<br>
> > > >> good. Imagine that you have several web services. You would like to<br>
> > > >> run a public WMS server and also another bunch of services for a<br>
> > > >> limited group of users. Having all the services available in both<br>
> > > >> instances would not be very good - e.g. with a WMS server you may<br>
> > > >> automatically provide WPS server.<br>
> > > ><br>
> > > > Looking at similar architectures, Geoserver seems to work this way,<br>
> > > > leaving to a security/configuration layer to enable and control the<br>
> > > > availability of the extensions.<br>
> > > > Anyway, we can avoid an automatic discovering, and control their<br>
> ><br>
> > exposure<br>
> ><br>
> > > > through a configuration system (eg a simple configurations file).<br>
> > ><br>
> > > GeoServer will provide WMS, WCS and WFS automatically for the data.<br>
> > > That could also QGIS server do by default. But with the gateway<br>
> > > interface QGIS could provide some custom services, maybe working<br>
> > > properly only with some specific data.<br>
> > ><br>
> > > Martin<br>
> > > _______________________________________________<br>
> > > Qgis-developer mailing list<br>
> > > <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> > > <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> ><br>
> > --<br>
> > Dr. Marco Hugentobler<br>
> > Sourcepole - Linux & Open Source Solutions<br>
> > Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
> > <a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
> > Technical Advisor QGIS Project Steering Committee<br>
<br>
<br>
--<br>
Dr. Marco Hugentobler<br>
Sourcepole - Linux & Open Source Solutions<br>
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
Technical Advisor QGIS Project Steering Committee<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br>