[Qgis-developer] QEP: QGIS Mapserver Python Plugins

[Martin Dobias]

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 <apasotti at 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