MS RFC 22a: Feature cache for long running processes and query processing (update)

[Howard Butler]

Tamas,

I think the proposal is a pretty cool solution, and I especially like  
that for the most part it behaves like any other layer.  I have a few  
questions/concerns:
- The proposal really continues our path to PROCESSING option  
hell :)  It would be nice if we could somehow make the parser not  
cough over (new) things it doesn't recognize (too late to go back in  
time to do that though).  I have no problem with what is proposed,  
this is just more a comment on our current free-form, alternative  
universe of mapfile syntax we have going on.
- The proposal doesn't state whether or not a cache layer will  
participate in the connection pool.  Is the handle to a cache layer  
intended to be kept alive like other connection handles across  
requests (ala FastCGI or some sort of always-on MapScript stuff)?   
Would it be reasonable to keep a connection handle to the  
"datasource" of all of the cache layers in the connection pool and  
then pull out references to already active cache layers?
- Is there any chance we would ever serialize a cache layer to disk?
- Will we ever do raster layer caching?  If so, MS_CACHE may not be  
what we want for a name for the enum...
- I would be interested in exploring the consequences of sub layers  
for MapServer layers.  Are these only to be cache layers, or could  
they potentially be *any* layer type?
   -- Also, are the sub layers references or copies (ala RFC 24)?

I admit I was pretty hesitant to have this go into the 5.0 release,  
but most of that was being unsure of what was proposed.  After  
reading through the proposal and patches, I think this will be a  
great addition for 5.0, even if it might not be fully baked and  
refined until 5.2 or 5.4.

Howard

On Jun 24, 2007, at 9:22 AM, Tamas Szekeres wrote:

> Hi All,
>
> In the meantime I've created the core implementation of the proposed
> changes. The MS-RFC-22a have been updated according to Steve's
> comments and questions.
>
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22a
>
> I've also constructed a sample scenario along with this RFC to
> visualize the power behind the concept.
> For the better readability I've also taken out most of the
> implementation code into separate patches attached to the
> corresponding ticket:
>
> http://trac.osgeo.org/mapserver/ticket/2128
>
> This RFC is still in discussion phase and I'm waiting for further
> comments and proposals. I also let you folks the decision whether this
> change is "simple" enough to paricipate in the upcoming release or
> not. Needless to say I'm pretty interested in the changes in my
> further projects but I don't intend to force anything against the
> majority of the community.
>
> Best regards,
>
> Tamas