MS RFC 22: Data adapter support

[Tamas Szekeres]

Frank,

>
> 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.

I hope that I can do this work within a few days. Most of the
fundamental points have been
mentioned in my previous postings in this thread. However I can see
that I've caused
a slight confusion by starting the same thread in both of the -dev and
the -users list.
Apologies.

>
> 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?
>

Every vtable function definitely provide access to the corresponding
layer object. Most of the
functions have a direct layerObj *layer parameter. The only exception
is LayerApplyFilterToLayer
where the layerObj reference should be retrieved using the layer index
if needed.

It's up to the developer which vtable functions are overridden. Inside
the vtable function
implementation the adapter will retrieve its own dataAdapterObj using
the layerObj.dataadapter
member. The adapter's internal data is stored inside the void*
adapterinfo member of the
dataAdapterObj structure.

Regarding to your question if the adapter must be aware of the changes
of a parameter it
should retain the recently known value inside the adapterinfo strucure
and compare to
the actual layerObj member at the beginning of the vtable function.
For example LayerWhichShapes is a good candidate do do this check do
determine if
the subsequent LayerNextShapes or LayerGetShape should be served from the cache
or reloading of the features should be done previously.

Using the mapscript interface the developer might want to handle the
cache reloadings
manually by calling the appropriate function of the adapter. In some
cases the developer
would want to separate the execution of the drawing and the cache
reloading using different
threads.

> 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.
>
I was thinking a lot of this approach but I couldn't find a convenient
way to do this.
Without changing any code I would be restricted to implement an externally
loadable layer of  type MS_PLUGIN. Actually I would not want to write an
externally loadable layer, and I cannot imagine how to configuration
of the original
layer will be brought into the picture.

You have mentioned to have a reference to another layer in the
mapObj's layer list
but it would be highly unmanageable from the perspective of the
adapter developer.
It would also bring in a high degree of confusion from the user's
point because she
would be incited to define extra layers that should be definitely hidden.

My primary intention was to provide built in support to modify the
behaviour of an existing
layer not to add new ones.

Best Regards,

Tamas