MS RFC 8: Pluggable External Feature Layer Providers¶
|Contact:||javerbach at extendthereach.com|
The purpose of this proposal is provide a way to user actually plug-in external third party feature layer providers to the MapServer at run time.
Provide a way to user to tell via map-file which library to load for layer, then load this library on demand and cache it for later use and bind it to the running MapServer by layer’s virtual table.
MS_PLUGIN_DIRwhich, if set, tells the base path for plugins
New MAP-file keyword
PLUGINwith string argument. This keywords tells which library dynamically to load for this layer.
The plugins are loaded based on the following algorithm:
- If plugin string is missing
.dllextension, append it to the plugin string
MS_PLUGIN_DIRis set and plugin string is not an absolute path, prefix plugin string with
- otherwise use plugin string directly
In general, the dynamic library loader will use system paths to seek appropriate plugin to load, if the path is not absolute.
- If plugin string is missing
New connection type
char* plugin_libraryin layerObj structure, this is the name of library to load for this layer.
Function to get virtual table for requested layer. If the library isn’t already loaded, it will be loaded on demand.
static const layerVTableObj * getCustomLayerVirtualTable(layerObj *layer)
layerVTableObjis the virtual table and layer is a custom layer. In case of error, function will return
Function to get a function pointer from dynamic loaded library. This function will also load the library.
msGetDynamicLibrarySymbol(const char *Library, const char *SymbolName)
This is implemented by GDAL project, and I have planned to use their implementation of this (
Cache structure for already loaded libraries. This cache structure will consist of a full name/path of the library (provided by user via mapfile), and a function pointer to the virtual table initialization function. The size of cache will be fixed and will be same as the maximum amount of layers (200 at the moment). This is the maximum number of different custom layers for MapServer which could be loaded at the same time. This cache implementation is internal, so if it has to be make dynamically allocated, it is possible to do later without breaking interface.
New lock item (
TLOCK_LAYER_VTABLE) to protect library cache structure.
Files and objects affected¶
This proposal will affect at least following files and objects:
layerObjwill contain a new field,
- New lock token
- New files and objects for custom layer handling.
Backwards compatibility issues¶
This change is binary incompatible, but mapfile backward compatible. It will add a new keyword which is unknown for old MapServers.
Vote proposed by Jani Averbach on 10/26/2005, the initial result was +3 and after amending RFC, got +4 (3 non-voting members).
Voting +1: Frank Warmerdam, Steve Lime, Yewondwossen Assefa, Daniel Morissette
Proposal passed and will move forward.
Plugin library has to implement function
int (*pfnPluginInitVTable)(layerVTableObj *, layerObj *);
which is called during library loading. This function is responsible
layerVTableObj * virtual table. If this function
leaves some function pointers to
NULL in this virtual table, then
default actions are used for these missing functions. The defaults
are visible in function
The function must not populate directly
layerObj->vtable, it have
layerVTableObj * argument for this. The MapServer is
TLOCK_LAYER_VTABLE lock during this function call.