Hey Andrea, Tim and I were chatting last night about a few improvements for wfs-v.
The first major goal is to make it easier to get the latest history without having to do two requests / tracking what revision we're at. What we came up with was to follow svn and allow users to do a toFeatureVersion or fromFeatureVersion of 'HEAD', which will be the current feature. So you could say something like:
<wfsv:GetLog
<wfsv:DifferenceQuery toFeatureVersion="HEAD" maxFeatures="20"/>
</wfsv:GetLog>
We need a few more things to make this work though. maxFeatures currently seems to have no effect, so we need to make it so it does. And things also seem to blow up if there's not also a fromFeatureVersion. I'm thinking we should have defaults for fromFeatureVersion of '1' and 'toFeatureVersion' of HEAD?
Does this make sense to you? How hard would implementation be?
The other improvement we were thinking of is that if you do a GetLog query and leave off any typename it should behave like DescribeFeatureType - that is it should grab information for all the featureTypes. In this case get the whole history. This way a client doesn't have to know beforehand what featureTypes there are (though I agree it'd be very rare that they didn't).
Finally, do we have a pluggable mechanism for new output formats for GetLog? I want to offer XML and JSON output for the log. Tim is actually using a GetFeature request on the changesets featureType because he likes the XML better. And because in the example requests it's a bit confusing the difference between that and a GetLog request. You agree that the history should always be gotten with a GetLog request, instead of doing a WFS GetFeature call? If so we may consider removing or at least moving to the end the WFSV_04_GetFeatureLog requests, so as to not confuse potential implementors.
Chris