Hi Alessandro, the concept is clear but I probably I was reading the worng repo: serverplugins-iface, which is the latest you authored. In this repo it seems that, in case a SERVICE different from the standards ones is called, an exception is raised [1], while in serverplugins repo the workflow is quite different, because the switch looks for plugin available to process the request.
However, what you're saying is that a plugin can completely change the incoming request and the outgoin request (I understand the middleware concept very well being a Django dev) and so: - have the opportunity to server a non-standard service - have the opportunity to do not let the request reach the QGIS Servers' request handlers. I will have a look to the filter examples later. Thanks for this work Alessandro ;) giovanni [1] https://github.com/elpaso/QGIS/blob/serverplugins-iface/src/mapserver/qgis_map_serv.cpp#L423 2014-10-24 8:31 GMT+02:00 Alessandro Pasotti <apaso...@gmail.com>: > 2014-10-23 20:20 GMT+02:00 G. Allegri <gioha...@gmail.com>: > > Hi Alessandro, > > I've read the latest version of the QEP and had a look to your repo. > > If I'm not wrong the current implementation doesn't provide custom > services > > as in the initial proof of concept, but gives the opportunity to define > > "middlewares" before and after the requests have been processed by the > > standard OGC servces offered by QGIS Server. Is it right? > > > > giovanni > > > > Hi Giovanni, > > Thank you for your interest in my work! > > You are partially right: the new implementation we agreed upon in > Hessen is loosely based on the Django concept of middlewares, with the > addition of the possibility to add new hooks (callbacks) in the > future. > > This implementation also allows for an easy implementation of custom > services though. > > In fact, this concept proved to be extremely flexible and unobtrusive > at the same time: a plugin can define one or more "filters" [1] with > an optional priority, the filters have access to server interface [2] > that in turn can manipulate the request handler [3]. > By manipulating the requet handler, a plugin can intercept and alter > the input (typically the query string) **before** entering the main > C++ switch for core services and/or can intercept and alter the output > **after** the main C++ switch. The output typically is one of: none > (in case the service did not match), an exception, an image or a > XML/HTML document. > > I have developed a test plugin [4] which implements the following filters: > > * an HTML remote python console, also implements HTTP BASIC > Authentication to give an example of HTTP header manipulation > * do nothing but logging the result of QUERY STRING manipulation > tests</li>\n" > * say HelloServer! and write some lines in the logs > * WaterMarkFilter: adds a watermark image on top of all WMS GetImage > requests > * raise and exception, catched in main loop > > Have a look to the filters for the implementation details. > > For anyone interested in testing, the implementation is in my > "serverpython" branch: > > https://github.com/elpaso/QGIS/tree/serverpython > > PLEASE NOTE THAT in a previous email I gave the address of a wrong > branch, that one above is the right one.: > > [1] http://www.itopen.it/qgis/serverplugins/api/classQgsServerFilter.html > [2] > http://www.itopen.it/qgis/serverplugins/api/classQgsServerInterface.html > [3] > http://www.itopen.it/qgis/serverplugins/api/classQgsRequestHandler.html > [4] https://github.com/elpaso/qgis-helloserver/tree/master/filters > > -- > Alessandro Pasotti > w3: www.itopen.it > -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer