MS RFC: Layer Plug-in Architecture

[Jani Averbach]

> Paul Spencer wrote Tuesday, September 06, 2005 3:16 PM
> 
> what will happen to mapscript code that changes the layer type on the 
> fly?  What about dynamically created layers?

The current proposal won't let you to do any of above.  Thanks for 
pointing this out. Below are possible solutions which I came up, 
could you and other mapscript people check them and verify if or not 
these are feasible things to do.  Other ideas are also warmly welcome.

When we have found a solution for this problem, I will amend RFC-3.

BR, Jani


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. 

***


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.


-- 
Jani Averbach