[Geoserver-devel] GEOS-235 -- information and proposed actions

GeoServer GeoServer Developer
1

Hey all,

I chatted briefly with aaime about this. I'll recap the latest comment
on http://jira.codehaus.org/browse/GEOS-235 and I'll propose two
actions.

Recap of situation:

* "updatesequence" is a mechanism to allow people to fetch the
capabilities document only when it's been changed. Otherwise they can
avoid downloading the entire huge capdoc and instead cache it locally.

* WCS 1.0.0 and WMS 1.1.1 both define pretty much identical behavior
around updatesequence. It's what I would call the "ad-hoc" style of
updatesequence. It's a bit loose in what is allowed to be in the
updatesequence parameter, but the behavior is well-defined and has been
"cut-n-pasted" from WMS 1.1.1 to WCS 1.0.0.

* OWS common 1.1 defines a "common" updatesequence behavior that needs
to be implemented by all services which are based on OWS common 1.1
Currently that is WCS 1.1.1 (not yet released) only.

* WFS 1.1 and 1.0 don't define updatesequence behavior at all. You can
read the spec to see the strange references to the updatesequence number
on the capdoc in 1.0, but there's no definition of how to add an
"updatesequence" parameter to the WFS getcapabilities request. It's as
though they just forgot to add that part to WFS 1.0. Wfs 1.1 is even
stranger in than it only includes a "legacy" spot in the schema for
updateSequence, and doesn't actually mention it in the spec at all.

Actions:

GEOS-235 includes patches which implement "ad-hoc" (only!)
updatesequence support for WMS 1.1.1 and WCS 1.0.0 on both trunk and
1.6.x

I propose that we wait indefinitely to implement "OWS common 1.1" style
updatesequence support. Whenever it becomes clear how to implement this
style, and when we have the need to do so, we can do it then.

I propose that we apply GEOS-235 patch-based updatesequence support (WMS
1.1.1 and WCS 1.0.0) on trunk now, and wait for 1.6.0 to go out before
applying updatesequence support to 1.6.x

If there are no objections, I'll commit that "old-style" updatesequence
support to trunk tomorrow sometime, and then whenever 1.6.0 goes out
I'll commit to 1.6.x

thoughts? comments?

--saul

2

Saul Farber ha scritto:

Actions:

GEOS-235 includes patches which implement "ad-hoc" (only!)
updatesequence support for WMS 1.1.1 and WCS 1.0.0 on both trunk and
1.6.x

I propose that we wait indefinitely to implement "OWS common 1.1" style
updatesequence support. Whenever it becomes clear how to implement this
style, and when we have the need to do so, we can do it then.

I propose that we apply GEOS-235 patch-based updatesequence support (WMS
1.1.1 and WCS 1.0.0) on trunk now, and wait for 1.6.0 to go out before
applying updatesequence support to 1.6.x
If there are no objections, I'll commit that "old-style" updatesequence
support to trunk tomorrow sometime, and then whenever 1.6.0 goes out
I'll commit to 1.6.x

Seems like a good plan to me. To make sure I understand, you won't commit the patches attached to geos-235, but only a version that affects wms, right? Last time I checked then ones on geos-235, they were imposing the wms behaviour on wfs requests too.

Cheers
Andrea

3

Seems like a good plan to me. To make sure I understand, you won't
commit the patches attached to geos-235, but only a version that affects
wms, right? Last time I checked then ones on geos-235, they were
imposing the wms behaviour on wfs requests too.

I updated the patches attached to GEOS-235. They only affect WMS 1.1.1
and WCS 1.0.0 now.

The updatesequence attribute/parameter is still read and parsed into all
requests (for WFS, WMS and WCS) but only WMS 1.1.1 and WCS 1.0.0 do
anything with it.

I'll apply the patches to trunk now, and will put a note to myself to
apply them to 1.6.x once 1.6.0 is out the door.

--saul