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
