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

[Tamas Szekeres]

Steve,

>
> Is Frank still a +0 or did you sway him... ;-)
>

I guess he will hold on to his -0   :-(

>
> My thought is that caching for queries is different than caching for
> long running processes.
> A query cache would in many cases stay resident for one execution only.

I'm afraid I don't see what you mean. Are you referring to the
execution lifetime of the process hosting the mapserver/mapscript
code? Could you expose the differences?

> I don't think we
> want to query the cache other than spatially. We'd always go back to
> the provider for certain
> queries (e.g. attribute). This is a discussion for the RFC for caching
> though.
>

Currenly every query is spatial to the effect that a spatial extent
should be specified at he WhichShapes call. Do you mean that we should
alter this concept?

> > I'm a bit disappointed about the inevitable copyShape when serving
> from the cache
> > since the caller has ownership of the features retrieved but I can be
> reconciled to
> > it for now.
>
> For certain queries you don't have to copy the shape since no clipping
> or coordinate
> conversion is necessary.
>

I'm afraid we shall always copy the shape if we are retaining a
reference to it at the cache. Currently the owner of the shapes
retrieved by LayerNextShape and LayerGetShape is the caller.

>
> > Support for cascading the adapters is the other point where one can
> > feel the solution a bit complex.
>
> I dunno, being able to apply multiple adapters might make sense. For
> example, if
> one adapter is a cache then why wouldn't you want to potentially buffer
> those
> features?
>

I think we might want to preprocess the features before placing them
into the cache and sometimes we would postprocess the features just
after retrieving them from the cache.
For example we might want to apply a GEOS ConvexHull operation to all
features before placing them into the cache. To achieve this we would
apply the GEOS filter adapter and the Cache adapter sequentially. We
should avoid integrating the 2 functionality into one adapter.

>
> I would advocate NOT using the PROCESSING parameter in favor of, say, a
> buffering
> adapter, or a general purpose GEOS adapter.
>

I think our goal is the same that is: the PROCESSING parameter should
be left to the original provider wihout altering it.


> >> 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.
>
> > Agreed. But I wouldprevent the developers from a flood of the RFC-s
> > as long as this one seems to be definitely unsupported.
> > But it would be interesting to see some performance measures so I
> will
> > go ahead with it
>
> Cool, appreaciate the willingness to dig in on a topic like this. Are
> you going to do
> so R&D first (e.g. get things working) or ??? There's probably more
> interest in talking
> about the caching than infrastructure- that's always the case.
>

I shall build up a test implementation to see how the things are
working in detail. And after I will write the RFC has been mentioned
before. However I cannot estimate how long does it take since I have
much of pending projects should proceed side by side.

Best Regards,

Tamas