Rob Atkinson ha scritto: > My assumption (hope, perhaps) is that this will allow Andrea to deliver > the capability via the OWS4 geoserver branch, which is aligned with 2.4, > and we dont need to break any rules or risk dissipation of release efforts. > > Enlighten me if I'm wrong here.
Sure. ows4 branch is not a working Geoserver. It's lacking UI and configuration subsystem. It's an implementation of WFS 1.1 and a study of the new Geoserver architecture to come. It's something that you have to configure by hand, don't remember if either by coding its datastore entries by hand, or by writing a small xml file (I believe it's the former), so it cannot be used by anything that should be user tested. It serves its purpose well because it just have to be hit by the WFS 1.1 CITE tests, so not having a UI and a configuration subsystem is not relevant. But for my work it's a roadblock. > Also, I'm involved in a number of data standards development processes, > and the issue of how versioning works is definitely tricky. I've been > on the road and havnt been able to follow all the discussions, but is > there a summary of how it is intended to reference versioned features > via a WFS call? Sure, here: http://docs.codehaus.org/display/GEOS/Versioning+WFS (if you're just interested in the implementation, see http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal). > If versioning information is pushed into the Application schema, then we > need nothing special, but versioning may be a convenience API for > transactions. Heh, that was my first idea as well. But it won't work, encoding a generic filter against version information would be a nightmare (encoding equality or simple comparison can be done, the rest would be really complex). It simply does not fit the way our jdbc datastore work, and I don't have time for a rewrite from scratch operation. > My idea is for versioning being an extension pattern for Feature Types > (i.e. a history points to feature instances, decorating any available > FeatureType with a common mechanism) - this fits quite well with the > getVersion() method, but we may need to expose a virtual FeatureType > "FeatureHistory" that we can query to access version history. Well, we have history as svn has, as a list of commits. But you can gather a full history of a feature as well. Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
