RFC for QGIS Server Python Plugins

Alessandro Pasotti (a.pasotti@itopen.it)


Not goals

Possible applications


Two possibilities:

  1. 404 handler - Simplest, hack-ish but unobtrusive and FAST! and KISS and DRY and [place your favourite pattern here!]
  2. Observer - Full-featured but with a minimal overhead and will require an heavy refactoring of the existing request handling code

Standard flow


404 handler


404 pros & cons


  • unobtrusive: just three lines of codes added to main loop
  • CGI-style plugins
  • Minimal overhead when FCGI starts
  • 0 (zero) overhead on core SERVICES: FAST!
  • re-use current Python Plugins loading mechanism
  • proof-of-concept simplest implementation done


  • no way to manipulate request and response generated from core services

Observer overview

Observer pattern: plugins will register themselves and listen to signals. Plugins will receive the request/response objects and they will be able to manipulate them:

Observer flowchart


Observer pros & cons


  • Provides all the possibilities to manipulate the request and response and extend QGIS Server


  • requires heavy refactoring of request handler --> request/repsponse handler
  • could introduce some (probably tiny) overhead even if there aren't any plugins installed/enabled

404 PoC Implementation Details

Example query string:


404 PoC metadata

Python methods (static!) are invoked and their output is captured and passed on to FCGI

Plugins exposed SERVICE and REQUEST methods are listed in Plugin's metadata:

Example metadata:


404 PoC methods

When all checks are done the plugin runs by calling the method in the REQUEST, the method receives:

The plugin (static) method has access to global python environment and can run arbitrary python commands, it can optionally return a content type string (the server defaults to text/plain).

The plugin CGI-style output is captured diverting stdout and stderr to a custom buffer which becomes the server response.

404 PoC example method

def SayHello(project_path, parameters):
    """Just say something"""
    print "HelloServer"
    return 'text/plain'

Example response:

200 OK
Connection: close
Date: Thu, 04 Sep 2014 09:56:36 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 12
Content-Type: text/plain
Client-Date: Thu, 04 Sep 2014 09:56:36 GMT
Client-Response-Num: 1


Observer refactoring


Observer current loop

The current main loop:

Observer refactoring

The new main loop:

Server iFace

Not sure about what should be exposed:

To GUI or not to GUI?

Should we use the same system for desktop and server plugins?

What is the (mostly) unique selling point of QGIS Server ?

GUI-based configuration of the map and the services!

A Server plugin can have (not must) a desktop interface aimed to configure itself

One-click install and deployment


An example plugin is available:


A running implementation of the sever plugins basic functionalities is available here:


Local test:

http://qwc/cgi-bin/qgis_mapserv.cgi?SERVICE=HELLO&request=GetCapabilities http://qwc/cgi-bin/qgis_mapserv.cgi?SERVICE=HELLO&request=SayHello http://qwc/cgi-bin/qgis_mapserv.cgi?SERVICE=HELLO&request=RemoteConsole http://qwc/cgi-bin/qgis_mapserv.cgi?SERVICE=WPS&request=GetCapabilities


If the plugin has a Desktop interface it cannot usually access to user's QSettings, this means that plugins options have to be stored somewhere else in order to be accessible by the server side.