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

[Umberto Nicoletti]

Hi Thomas,
I followed mod-geocache since the initial announcemente and I'm really
impressed.
I'll reread the rfc it tomorrow and let you have my thoughts by the evening.

Best regards,
Umberto

On Tue, May 24, 2011 at 10:21 AM, thomas bonfort
<thomas.bonfort at gmail.com>wrote:

> 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
> >
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110524/c1005bab/attachment.html