MS RFC: Layer Plug-in Architecture

Tamas Szekeres szekeres.tamas at FREEMAIL.HU
Mon Sep 12 17:04:21 EDT 2005


Hello Jani,

Actually I was thinking of this proposal as a kind of interface design
pattern which could represent the layers polymophically for the clients
depending on the type.

In this case may I suppose the mapscript interface will remain unchanged?



Best Regards,

Tamas Szekeres






On Mon, 12 Sep 2005 10:14:21 -0600, Jani Averbach
<javerbach at EXTENDTHEREACH.COM> wrote:

>> -----Original Message-----
>> Tamas Szekeres wrote on Friday, September 09, 2005 3:10 PM
>
>Hello Tamas,
>
>> Could you point me to a working sample implementation that utilizes
>> the concept of this proposal in order to review the possibilities of
>> mapping with SWIG C#.
>
>There isn't anything working which is strictly based on this
>RFC. However, I posted to the MapServer-dev a prototype patch which
>implemented plug-in architecture for MapServer. The message was:
>
>Message-Id: <smtpd.489f.4303bde2.8dbaf.f at mtaout-w.tc.umn.edu>
>Date:         Wed, 17 Aug 2005 16:44:44 -0600
>Subject: Mapserver Plug-in Infastructure: RFC and PATCH
>
>
>> It seems this solution requires a run time cast on the vtable at the
>> client side, but I couldn't see how to enforce the client to use the
>> proper fn signature depending on the type of the layer. Is the
>> vtable layout static for a particular type?
>
>The main idea is that the vtable is a private data for layer, so you
>are not supposed to call any layer functions by yourself by vtable.
>Instead you should use existing layer functions e.g..  'msLayerIsOpen',
>'msLayerWhichShapes' and so on. What happens internally is that these
>calls are multiplexed by vtable instead of static switch.
>
>Also the vtable layout is static for all layers, so all layers will
>share same vtable structure layout and the vtable function signatures
>will be same for all layers.  This vtable interface is an abstraction
>layer how MapServer sees all layers and their common operations.
>
>I hope that this clarified things.
>
>BR, Jani
>
>--
>Jani Averbach



More information about the mapserver-dev mailing list