[UMN_MAPSERVER-USERS] MS RFC 22: Data adapter support

[Tamas Szekeres]

>
> > You have mentioned to have a reference to another layer in the
> > mapObj's layer list
> > but it would be highly unmanageable from the perspective of the
> > adapter developer.
>
> I'm not sure why referring to another layer by name would be
> difficult from the adapter writers perspective.
>
> > It would also bring in a high degree of confusion from the user's
> > point because she
> > would be incited to define extra layers that should be definitely hidden.
>
> This is a concern, but it seems to be a line we already crossed with the
> above illustrated approach to tile indexes.
>

Frank,

I have several problems with this approach as for example:

1) I cannot really know how to retain the adaptor layer's internal
data between the
subsequent renderings and the queries. Definitely we have a void *layerinfo
member dedicated to accomplish this task. However the structure holded
by the layerinfo member should be destroyed during the LayerClose call because
currently we have no mechanism to get informed when the layer was destroyed.

2) Every vtable functions should be propagated to the referenced
layer. There's no
chance to leave some of the functions alone with the original provider
(similarly to
the inheritance and function override with the OO notation).

3) Currenty I have mapfiles having hundreds of layers working
properly. Having twice as
much layer might kill the performace increment i am addressing with
the caching implementation ;-)
And also the overall size of the mapfile is higher.

4) From the users perspective she will have 2 layers dealing with the
same layer rendered
in the map. It will be much confusing which properties and methods of
which layer should be used in
a particular situation. Theoretically these two layers would be one
layer in effect.
At this point I feel we would give up the clarity of the interface in
exchange for saving
some extra work.
Needless to say that the proposed changes would not disturb the
original mapserver code
so much.

> I'd add that some of the semantic confusion here comes from the fact
> that we have a mixture of data access operations (different connection
> types, filtering, etc) and layer presentation (classification, styling)
> all mixed into the layerObj.

That might be true but even some of the data sources may also contain
meta information about the presentation of the data.

>
> PS. I've taken the liberty of just replying to -dev.
>

Me too.


Best Regards,

Tamas