GeoWebCache

1) Too many options I think on the stuff they have covered they have done a pretty good job. I am somewhat surprised that so many presentation layers (KVP, RESTful, SOAP) are treated directly in the specifications. To me it seems like it's almost forcing everyone to support all of them. Which is not hard, but not a particularly good use of time either. Why not mandate KVP ?

The introduction starts about popularizing WMS through caching, but I do no think there are adequate mechanisms for updating tiles, and OGC standards generally make poor use of the HTTP protocol.

2) The matrix definition does not make a distinction between the grid and the data extents

You may for instance want to a) Start with a relatively small dataset, but later expand to new areas without throwing out unaffected tiles (for example through updates through WFS-T) b) Use a well-known scaleset, such as GoogleMapsCompatible, but not serve tiles for all areas

GeoWebCache currently deals with these cases by serving transparent PNGs to requests that fall outside of the covered areas, but it would be better if the client had some way of discerning the two. One way to do that would be to have the getcapabilities document include information about min/max row/column. In some sense this is already available through the Lat/Long bounds, but it would be better to specify it directly in the layer description.

3) The draft does not consider important topics such as expiration headers, conditional gets (last modified) or etags.

All of these values are generally available to caches and therefore easy to implement.

Additionally, the same way the getcapabilities document has a sequence number, it would be a good idea to have such a number, or a last-modified timestamp, in the layer section. All of the above should be optional, but mentioning them would encourage clients to check for these values and thus allow for much more dynamic services.

4) Why not use HTTP error codes in addition to the exceptions, for other services than RESTful? I need to double check "Subclause 7.4 of [OGC 06-121r3]", but it seems like you may have to parse the output to detect problems.

5) Defaults are powerful incentives Why not make tileWidth and tileHeight optional and default to 256 x 256. Or 200x200. I realize that this may lead clients to only support the recommended tilesize, but a recommendation increases the likelihood of interoperability.