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

[thomas bonfort]

Steve,

Based on the recent evolutions concerning proxying that were added to
mod-geocache, I was thinking along the same lines you were.

Sharing the mapserver mapfile as a configuration file had the primary
advantage that mod-geocache had access to the same metadata
information for generating the WMS getcapabilities response. With the
proxying support now available, I'm more and more inclined to not let
mod-geocache create the capabilities response, and let it proxy it to
mapserver: mod-geocache would do what it does best, i.e. just serve
tiles, not become a full wms server on its own.

This would have the primary advantages of not having to maintain
capabilities creation in mod-geocache, and keep it available as a tile
server in front of non-mapserver sources.

I see some drawbacks with the solution however:

- tiles are seen as a single WMS layer for mod-geocache, but can be
mapped to multiple WMS layers in mapserver (eg: mod-geocache layer
"mytileset" corresponds to mapserver layers
"basemap,roads,buildings"). This could be overcome if the layers in
the mapfile are configured with a GROUP that corresponds to the
tileset name, i.e. GROUP mytileset. Another rather hacky solution
would be to call the mod-geocache layer "basemap,roads,buidlings".

- The capabilities created by mapserver and proxied by mod-geocache
are not aware that there is a cache in front of the service. As such
the onlineresources would probably be wrong, and there would not be
the WMS-C vendorcapabilities added advertising the cached layers. With
some further development effort, mod-geocache could be extended to
parse the returned xml capabilities to correct the onlineresources and
add the wms-c blurb. I'm personally not a very big fan of WMS-C as it
is missing some major functionality to make it usefull in all but the
trivial cases (i.e. no support for multiple grids/srs per layer, and
no support for dimensions)

regards,

thomas

On Wed, May 25, 2011 at 06:15, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> Hi Thomas,
>
> Sorry for not responding earlier, I have been traveling and not had access.
>
> I think the one of the high value features of mod_geocache, is the fact that
> it is easy to setup and works with any WMS source providers. Another high
> value feature is that this uses proxy pattern which makes it high useful and
> can stand on its own.
>
> So, I concerned about what value add we get from say having it read a
> mapserver mapfile versus a mod_geocache config file. If I'm so non-mapserver
> WMS source to work with mod_geocache, why would I want to create a mapserver
> mapfile?
>
> In addition, I see publishing tiles more as an end point that is relatively
> static so I would not think that the mapfile would be changing dramatically
> so the tighter integration of directly reading the mapfile seems to be a
> limited value, but maybe this is just a factor of my normal use cases and
> other might have differing needs.
>
> I think there is good value in integrating the governance of mod_geocache,
> and possibly optionally allowing the mod_geocache config file parser being
> able to reference a mapfile to get its information, but it should not be
> required for projects if they want to use mod_geocache.
>
> You and I had discussed adding security in the past and after thinking about
> this some more, I have this idea stuck in my head that we should implement
> this via something like a cascading proxy servers so we can keep each proxy
> clean and focused. So something like:
>
> WMS request--->[ACL security proxy]---->[mode_geocache]--->[WMS server]
>
> This same model could be adapted to tinyows if the ACL security proxy was
> extended to parse and validate WFS-T requests. Maybe the GeoPrisma team has
> more input on the security side of things.
>
> -Steve W
>
> On 5/24/2011 5:26 AM, thomas bonfort wrote:
>>
>> On Tue, May 24, 2011 at 11:20, Olivier Courtin
>> <olivier.courtin at oslandia.com>  wrote:
>>>
>>> On May 24, 2011, at 10:21 AM, thomas bonfort wrote:
>>>
>>> Hi Thomas,
>>>
>>>> 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 use case also handle POST datas sended ?
>>
>> good point. mod-geocache currently does not support POST, and this
>> should be added.
>>
>>>
>>> Could we imagine to enhance these proxy, in future, to add security
>>> filtering
>>> (auth, ACL check...) ?
>>
>> mod-geocache does not support those. I'm not sure if that would be its
>> role or if that should be dedicated to another module kicking in
>> before.
>>
>>>
>>> --
>>> Olivier
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>