MS RFC: Layer Plug-in Architecture

[Stephen Woodbridge]

Jani,

Would it make sense to treat change layer type like a create/clone new 
layer followed by a delete old layer. Then the implementation would be 
equivalent to to the first problem. When you create the new layer all 
the information is cloned from the existing layer and the connection 
type is set up appropriately for the changes requested followed by the 
delete.

-Steve W.

Jani Averbach wrote:
>>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.
> 
>