MS RFC: Layer Plug-in Architecture

[Tamas Szekeres]

Hi,

In my opinion the MapScript interface should enforce the consistency of
the state of the layer object so some of the directly accessible member
variables should be replaced with the corresponding (get_, set_) accessor
functions. When changing the connection it makes the possibility to do
some extra work eg. releasing the resources of the previous connection.

However, I can't see the reason of copying the layer instance before
changing the type of the connection. Instead, it would be desirable to add
some extra functions the client could explicitly reset the state of the
object with.


Best Regards

Tamas Szekeres



On Mon, 12 Sep 2005 15:38:52 -0600, Jani Averbach
<javerbach at EXTENDTHEREACH.COM> wrote:

>Hello,
>
>If you are interested in MapScript then please read on.
>
>The biggest open problem with MS RFC-3 is what to do with layer
>mutating (i.e. changing type of existing layers) from MapScripts.
>
>I am going to amend the RFC-3 by following way:
>
>1) The vtable will be initialized when any of the MapServer's layer
>   functions is called for the layer first time. This makes it
>   possible to build layers on-the-fly field by field with MapScripts.
>   No extra initialization is needed for new layer.
>
>
>2) To change the type of existing layer, following conditions have to
>   be met: The to-be-changed layer instance has to be a copy, you can
>   not change layer type without copying the layer instance first.
>   Secondly, the change of connection type has to be made by function
>   call, with connection type and optional library name as parameters.
>   This will break existing scripts which modify directly connectiontype
>   field.
>
>So far Sean and Frank have shown support for #2, I will include the second
>option at the end of this email.  If you feel strongly against #2,
>please speak up now so we can sort out issues before
>voting/implementing this.  If the second point is too controversial,
>we could implement it a backward compatible way, and tell that
>modifying directly connectiontype is deprecated and will be removed in
>the future.
>
>Thanks,
>Jani
>
>
>Another solution for layer mutating:
>
>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 vtable will be
>switched on-the-fly 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 actual information which library and hence backend to use, is
>  stored elsewhere in the layer.
>
>--
>Jani Averbach