Tamas Szekeres wrote:
Steve,
This RFC would establish the infrastructure to write data adapters but not
addressed to deal with a particular adapter implementation. I think it's
not
so easy to digest these things in itself and would not want to introduce
new
issues into this proposal.
However I am planning to create an additional RFC specifically to the
proposed
feature cache implementation, but I would like to see how this one is
acceptable
by the others, because that RFC will highly rely on this RFC.
Tamas,
I think it might be helpful to prepare an RFC 23 for a caching data adapter
in detail based on RFC 22. From what I can see so far of your description
of a caching adapter, I find it somewhat disturbing, though perhaps I am
viewing this in a wrong headed manner.
One scenario that occurs to me is, how would caching data adapter know when
to invalidate it's cache due to changes in lower level adapters or the
layer itself?
For instance, if mapscript is used to explicitly alter the FILTER on a layer,
how would a caching data adapter know to invalidate all it's current cache?
I'm also still feeling that the existing layer plugin mechanism could be
used to implement the equivelent to data adapters without changing any code
in mapserver.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
