On Wed, Jan 5, 2011 at 6:30 PM, Gabriel Roldán <[email protected]> wrote:
> Hi all,
>
> as per http://jira.codehaus.org/browse/GEOS-4163, there's now the
> possibility of directly integrating GWC with the regular WMS, providing
> WMS-C capabilities directly out of the GeoServer WMS:
>
>      * There's the possibility to enable direct GWC WMS integration
>        through the UI (disabled by default)

Nice

>      * The gwc module intercepts regular WMS calls, and if direct WMS
>        integration is enabled, it will check whether the request comes
>        with TILED=true AND matches a cached tile, and if to, will serve
>        the cached copy. Otherwise it defers to the regular WMS call.

I see this has been done using Spring AOP, good.
I hope this means it's still possible to remove all GWC related jars
from GeoServer
and have it working fine.
This is imperative for the WMS performance shootout, always removed GWC entirely
to prove that no caching was going on (or was possible) in the tests.

Also, there is a concern that GWC embedded in GeoServer can turn into a disk
killing bomb: the tile caches can become rather large, as an administrator I'd
like to have GWC around only if I really need it, and to configure it tightly
to avoid misuse.
The default GWC configuration instead does not prevent that, which is one reason
why I normally get rid of it unless I'm actually going to use it and
configure it
in detail (btw, is the quota functionality ever going to be included
in GeoServer
GWC? That's something every conscious admin should configure, along with
the other service limits).

>      * if the getcapabilities request comes with TILED=true, the gwc
>        module contributes the WMS-C VendorSpecificCapabilities, adding
>        an internal DTD definition for TileSet/Resolutions/etc and one
>        TileSet per cached layer/CRS/output format combination.
>      * the GetCapabilities namespace vendor specific parameter is
>        respected, so that if the request comes with namespace=topp,
>        only TileSets for layers in the topp namespace will be added.

Nice and nice.

> Note, however, that the default geoserver layer preview demos won't hit
> the cache because they calculate the tile origin based on the layer's
> bounding box, which generally doesn't match the GWC's gridset tile
> origin. But the WMS caps providing the WMS-C extended capabilities
> (specifically the TileSet definitions) do make it possible to create OL
> apps that match the layer's gridsets.
>
> It would be nice to have the layer preview match the gwc gridsets by
> default, but so far it's not such an easy task as the openlayers map
> output format is decoupled from the gwc module.

I guess it would be nice, but it would be better to do that only if GWC
is around, and without introducing a dependency. Some sort of
extension point?
Wondering if the extension point that is used to declare the tilesets
extensions in the capabilities could be also used to drive the OL
preview configuration.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584962313
fax:     +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to