MS RFC 22: Data adapter support

[Frank Warmerdam]

Tamas Szekeres wrote:
> Folks,
> 
> According to the mapserver 5.0 development plan
> http://mapserver.gis.umn.edu/development/release_plans/mapserver_5_0
> we have planned to implement feature cache support for long running
> processes and query processing. This support will increase the
> performance of the long running processes by maintaining the features
> from a previous query in an internal memory cache.
> 
> The first step to implement this feature is to provide a framework to
> modify the behaviour of the  existing providers in an unified manner.
> The changes described in RFC 22 will address this issue.
> 
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22
> 
> Any comments and suggestions will be appreciated.

Tamas,

Generally speaking I like the idea of being able to specify a series
of operators to be applied to features returned by a feature store in an
orderly manner.  In some sense this is similar to the OGR VRT mechanism,
but by doing it within the mapserver core, we can provide equivalent
behavior for all feature sources.

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.

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.

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.

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

So, at first blush, I find myself being "-0" on the idea.  I don't object
strongly, but I don't find the usefulness necessarily justifying the
extra complexity implied by the construct.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org