MS RFC 22: Data adapter support

[Tamas Szekeres]

Frank,

>
> However, I'm not confident that it is solving a problem that we actually
> have.  I don't think it actually helps to solve the query result caching
> problem.  It could be used for implementing geometry-from-attributes in
> a manner to OGR VRTs, but I think it is relatively uncommon for us to need
> to do this from the builtin datasources.  I can think of some other uses
> for this, but they seem somewhat esoteric.  Without some additional concrete
> use cases, I'm hesitant to engineer in this substantial additional complexity.
> Both because additional complexity is bad in and of itself, and because it
> is hard for me to be confident that we have thought through all the
> implications.
>

Since the data adapter can take control over all of the functions to
the data provider
i think it's much enough to populate the layer level cache with
features. Since we will
retain the feature of at least the previous rendering (or more). The subsequent
queryByXXX can be handled from that cache.

> I'd add we could accomplish something similar now just by having "plugin
> layers" or other specialized layers that refer to other layers are their
> raw data source.  So, essentially chaining layers instead of maintaining
> a stack of adapters.

Since the data adapter can take control over all of the functions to
the data provider I'm
considering the cascaded layer philosophy would be equivalent from the
programmer's
perspective. And I think that the actual problem could be solved by each.
However the latter will bring in extra complexity by creating and
additional internal
layer inside a provider. And also I can't really imagine how this
solution could be
controlled by the mapfile or by the mapscript API repectively.

Theoretically I would write a builtin support for caching features
from any of the
providers but i would not want to implement a new provider eg.
MS_FEATURECACHE_PROVIDER along with MS_OGR or the others. This problem
requires to extend the functionality of an existing provider not to
write a new one.

>
> In a very loose sense, this is how we use tileindex layers as a special
> datasource just used by another layer to select tiles to read.
>

As far as I know currently the tileindex support is implemented by the
providers separately.
I cannot see an uniformized decoupled implementation for this problem.

> And of course, currently, most "feature transformation" type operations
> are accomplished using mapscript.
>

I consider there operations are less effective than binding the work into the
core mapserver code. I guess it would require to create inline layers
on the map.


Best Regards,

Tamas