MS RFC 22: Data adapter support

[Tamas Szekeres]

Frank,

>
> I'm not really completely certain how it would work in practice though.
> I'm not sure it would be good to keep around features fetched for drawing
> purposes.  I had in the past assumed we would just store features instead
> of feature ids in the resultCacheObj - in which case the caching would
> only affect queries, and wouldn't increase memory use during the normal
> render loop.
>

I would support caching not only for the feature query but also for
the subsequent
renderings as well. Therefore at least the features of the previous
rendering would be
retained in the cache. Alternatively the user could configure the
adapter for fetching
features for an enlarged rendering area or for the entire area covered
by the layer.
The RFC for the feature cache will address the applications being
capable to maintain
long lived internal reference to the map object. This kind of
application will tolerate the
increased memory footprint in exchange for the higher rendering and query
performance.
I would also support adapter dependent custom actions to be performed using the
mapscript API such as loading the features into the cache. This action could be
implemented thread safely so prefetching the features could be done even from a
background thread.

>
> Note, I was suggesting that "adaptor layers" would reference another
> raw feature data source layer by name, rather than nesting it within
> the layerObj.  This is analygous to how the tileindexes are referenced
> from other layers.
>

At this point I cannot figure out how this approach would be realized.