MS RFC: Layer Plug-in Architecture

[Sean Gillies]

I was chatting with Jani on #mapserver yesterday, and here's my 
perspective:

On Sep 8, 2005, at 9:38 AM, Jani Averbach wrote:
...
> Objectives:
>
>  i) It should be possible generate on the fly layers, existing
>     mapscripts are doing this.
>
> ii) It should be possible to change on the fly the type of the
>     existing layer, existing mapscripts are doing this.
>
>
>
> First objective (generate layer on-the-fly), Solution:
>
> Delay load layer's vtable when layer's function interface is used
> first time. No additional vtable initialization is needed when you
> create a layer.
>
> ***
>

Fine with me.

>
> Second objective (mutate existing layer), First solution:
>
> Add an extra field to the vtable, which also tells connection type.
>
> Then add to the layers interface functions a logic that if vtable's
> and layer's connection type are different, then on-the-fly switch
> vtable to reflect layer's connectiontype.
>
> This solution will bring few consequences:
> - Per every layer function call we have to do few extra check
> - For custom layer functionality, we have to provide an encapsulated
>   interface to change from one custom layer to another because for
>   different custom layers, the connectiontype is same i.e. CUSTOM,
>   and the actual information which library and hence backend to use,
>   is stored elsewhere in the layer.
>
>
> Second objective, Second solution:
>
> Require that you can't directly change connection type and provide a
> function for this operation.
>
>    int ChangeConnectionType(int type, const char *library_str)
>
> where type is connection type and library_str is a path to the dynamic
> library to load, if custom type.  For internal types this second 
> argument
> is NULL.
>
> To get this really working and to prevent bugs, we should not let
> users to edit directly layer.connectiontype, so it should be removed
> or make read-only from scripting interface.
>
>
>
> Second objective, Third solution:
>
> Remove this feature and don't let users mutate existing layers.
>

Now that I think of it, I *do* allow something like the 
connectiontype/data mutation hack in my PCL project. PCL layers are 
free to switch between data stores. We don't have a separate data 
source object in MapServer, the concept is parameterized by multiple 
attributes of layerObj. I am no longer opposed to layer mutation as 
practiced by Paul, Howard, and others.

I prefer solution #2. How about calling the method "connect()" and use 
the same parameters. We're doing more than just changing the 
connectiontype, we are connecting the layer to a backend.

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://zcologia.com