Hi Alessandro Finally I had some time to look at your proposal (your mail and the proposed QEP [1]). I am not that much involved in the QGIS server development, but the Python word in the thread subject always draws my attention :-)
On Thu, Aug 28, 2014 at 7:49 PM, Alessandro Pasotti <apaso...@gmail.com> wrote: > > The rationale behind server plugins is doublefold: first they could > provide additional services without the need to touch the C++ > codebase, second they allow for GUI-based configuration since the > server plugins are not separated from the desktop plugins (of course > the environment and permissions should be carefully configured to > allow information sharing from the desktop user to the webserver user > ). I understand the first reason (use python instead of c++ to extend the server), but I am not sure I see the second reason (allow GUI-based configuration). Actually I find that mixing of desktop and server plugin functionality is not making things any better than having two separate plugins, one for desktop and one for server. They are meant to be running in two completely different environments, it may be a good idea to treat them in such way. Still I guess having some kind of plugin functionality also in server may be useful. At the same time I think in many cases it would be actually better to have the functionality in python plugin (e.g. WPS server based on processing framework) completely separated from QGIS server and run it through an ordinary interface for Python (WSGI). One could even employ some Apache rewriting rules to make the impression that the service is still handled by QGIS server. You mention that this is just an early prototype to see where things can go, so I understand some things are quite hacky / experimental. If the team is happy to proceed with the concept of plugins for QGIS server, here are some things I think need changing compared to the current proposal/implementation: - we need proper object-oriented approach for the plugins. Like QGIS desktop provides QgisInterface instance for plugins, QGIS server should also provide some kind of QgsServerInterface which would be used by server plugins. Such interface would give the plugin access to all data structures it needs (e.g. parsed project). - in the server there is already QgsOWSServer interface which existing services derive from. Plugins should be also base on that interface (may need some further work) - the output from plugin should be abstracted - in the server there is already QgsRequestHandler interface for such things (may need some further work) - loading of plugins should be done in a very similar way to desktop plugins - similar to "classFactory(iface)" entry point, there could be "serverClassFactory(iface)" entry point that returns instance of running server plugin - I don't like the fact that plugins declare their "service" and "methods" in metadata.txt. I think plugins should register their QgsOWSServer implementation to server interface when they are loaded. This is more flexible - a plugin may register more services or provide some extra info during the registration Cheers Martin [1] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/3 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer