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
