MS RFC 22: Data adapter support (void of interest?)

Steve Lime Steve.Lime at DNR.STATE.MN.US
Thu Oct 26 14:12:56 EDT 2006


I was sort of sitting back and watching where the discussion with Frank
was going
to go since you both are amongst the most technically skilled and then
comment a bit. 
I confess to being a bit lost in the technical details of RFC 22.

One thing I did notice is that for queries to work "as is" the adapter,
specifically the
cache adapter would need the ability to retrieve features by unique ID
or better
yet member shapes would need to be cached by hand from the msQueryBy...
functions
so we could pull them sequentially for presentation.

My thoughts on caching are that it is very much necessary. I was
thinking mostly
from a query perspective but do set the value in a long running
process. When I
had thought about implementation it I was thinking that caching would
be independent
of the underlying datasource. That is, a filter that would sit between
MapServer 
drawing and query functions. That way we wouldn't have to change in the
existing
code base at all, nor would virtual providers have to worry about
anything. Layer
configuration for caching would be simple, STATUS On/Off/Query,
SIZE/TUNING 
parameters and that's about it.

Your proposed solution goes well beyond the simple notions I had been
thinking
about. Also I was mulling over how to put GEOS functions in the
pipeline (e.g. 
buffer a feature before drawing or querying with), and could only come
up with
using the PROCESSING tag so this would be better.

I think it would be helpful to write RFC 23 on the caching adapter so
they can
be considered in tandem, that is, a concrete example of the benefits of
RFC 22.

Consider this more than mild support.

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 10/26/2006 11:46:09 AM >>>
Developers,

I can see that not too much people are interested in the issues of the
long running processes and therefore this RFC could not reach that
level of discussion to be eligible to call for a vote on it. The
primary aim of this RFC was to establish a connection point where the
feature cache implementation could have been integrated into mapserver
in a loosely coupled manner. I wanted to generalize this solution for
being usable to solve other issues (if any) related to the data
providers of layers.

Since I cannot see even a mild support about the objectives of this
RFC (except for SteveW in general) neither a compelling alternative
solution was suggested I guess it would be reasonable not to spare
more efforts on this issue and revoke the RFC accordingly.

It would be helpful to get some confirmation or denial about what
should I have to do so as not to keep this task open in my timeline.

Best Regards

Tamas



More information about the mapserver-dev mailing list