[mapserver-dev] Re: ms rfc 71: mod-geocache integration

[thomas bonfort]

no comments?

I would think that the proxying nature of mod-geocache integration
needs discussion. The scenario is as follows:

* user creates a mapfile that needs tilecaching support, placed at
/path/to/mapfile.map. This mapfile contains some configuration
keywords to declare what layers are to be cached, the definitions of
the tile grids that will be used, where to store cached tiles, etc...

* apache configuration is set like:
<Location /mymapservice>
  SetHandler geocache
  GeocacheConfigFile /path/to/mapfile
</Location>

* user publishes the url to his service as http://myhost/mymapservice
* incoming requests to /mymapservice are treated as follows:
  * WMS requests that correspond to tile requests of a cached layer
are intercepted by mod-geocache
  * WMS requests that correspond to general getMap requests of a
cached layer are treated by mod-geocache and are reconstructed by
assembling cached tiles (or forwarded to mapserver if configured so)
  * non wms tiled requests are treated by mod-geocache, on the urls
http://myhost/mymapservice/(wmts|tms|kml|etc...)/
  * all other requests (WMS on a grid with different SRID, WFS, WCS,
etc...) are forwarded to http://localhost/cgi-bin/mapserv (or another
server+path)?map=/path/to/mapfile&(forwarded incoming request params).
With some configuration, the user can also configure specific requests
to be forwarded to a specific url, eg WFS-T requests go to
http://localhost/cgi-bin/tinyows.

This scenario has the advantage that the mod-geocache configuration
and operation is quite decoupled from the mapserver one, and allows
the publication of a single entry point into *all* the services
offered by /path/to/mapfile.map. It has two inconveniences:
 * all non tiled requests are proxied, and therefore go through a
second http request. This adds the overhead of mod-geocache parsing
(which is minimal as it consists of checking the service is WMS, then
that the requested layers are cached, that the SRS corresponds to the
layer's tile grid, and optionally finally that the extent+size matches
the configured tile grids), plus the overhead of a second http request
(which should be minimal as it happens on localhost or the local
network).
* WMS GetCapabilities responses are generated by mapserver, and
therefore would not contain the WMS-C extension indicating that
there's a cache available. We could imagine that mod-geocache
intercepts the mapserver-generated xml, and inserts the WMS-C vendor
extension required to publicize the tiled service.

--
thomas

On Fri, May 20, 2011 at 17:22, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> I've committed a draft version of rfc 71 here:
> http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-71.txt
>
> awaiting your comments...
>
> --
> thomas
>