MS RFC: Layer Plug-in Architecture

[Howard Butler]

Tamas,

>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.

That's a whole 'nother RFC... The convention of accessing layer member data 
directly (without the get_ and set_) method has been around for a long time 
in MapScript, and lots of code has been developed that (for better or 
worse) depends on that convention.  Turning over this apple cart in the 
name of purity now would cause unending frustration for the significant 
code base that is already out there.  I like clean, consistent, 
loosely-coupled, and orthogonal APIs as much as the next person, but we're 
already on this path... MapScript may have its warts, but I love it the way 
it is ;)

Also, there are ways around this... For example, in 4.6 or 4.4, 
mapobj.extent was overloaded with a Python property to call 
mapobj.setExtent() and .getExtent()  to still maintain the old behavior 
(because the extent data member could no longer be set directly because 
some magic had to happen when an extent was set).  Maybe we can have our 
cake and eat it too, but I'm not sure this strategy is possible in every 
scripting language.  I expect that overriding the connectiontype in Jani's 
option #2 will be implemented this way in Python Mapscript at least to 
preserve compatibility with existing code.

>When changing the connection it makes the possibility to do
>some extra work eg. releasing the resources of the previous connection.

The only point I would like to make is that the user of the public side of 
a layerObj shouldn't have to care at all what the connectiontype is.  It is 
my hope that when I have a handle to a layerObj, I shouldn't have to care 
that it is actually a "on-the-fly postgis layer" that I have to remember to 
free up the sql results of, or a OGR VRT layer, or SDE, etc.  If I have to 
remember to do anything extra or special as a scripter because the layerObj 
I have is of a certain connection type, the concept of a layerObj is 
completely busted, IMO.


>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.

As I mentioned on IRC, I use this prototype pattern quite frequently 
because it is so tedious to build up a layerObj from scratch in scripting 
land.  In my MapScripts, I tend to clone existing instances and then modify 
the bits that I need (connections, styles, etc).  I don't know that it is 
the *right* way, but it is more convenient and has less boilerplate for 
me.  Also, if you are a PostGIS or Oracle Spatial user, creating layers 
on-the-fly with MapScript is often the best way to accomplish certain 
things (by controlling what data is displayed using SQL in the DATA 
member).  See <http://hobu.biz/software/OSGIS_Hacks/geocode.py> for 
examples of completely creating layers on the fly in Python MapScript.


>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