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

[Steve Lime]

I'll bite off smaller chunks for more discussion. Comments inline...

>> How would do you see configuration of a capability like that? For example, a typical buffer operation would have a distance, perhaps units and maybe a corner tolerance.
>
> Any provider specific information would go into the metadata section
> of that layer. So in this case we could use the following definition
> example:

We also have the PROCESSING section that I wonder if might be more appropriate than METADATA. Frank uses it as a mechanism to define raster processing parameters and already has access routines available. Would be nice to be consistent regarding configuration as new processors become available.

> LAYER
>     CONNECTIONTYPE BUFFEROPERATION
>     METADATA
>         "distance"  "23"
>         "units"   "meters"
>          ....
>      END
>      LAYER
>          CONNECTION "any other layer"
>      END
>  END
> 
>  I would also allow to specify the operation parameters as feature items, like
>  METADATA
>      "distance"  "[distanceitem]"
>  END

>  The most trivial implementation of this buffer provider is to allow
>  only the nested layer specification and propagate every vtable
>  functions to the inner layer. The operation should be applied on the
>  features retrieved by the NextShape and GetShape calls respectively.

So this could be used in a non-caching environment without issue then?

Steve