Ok, great work on digging in to this, this is definitely deeper than I've gotten. My thought has always been to 'get something out there' - that could potentially grow in to bigger and better uses, but that may need a refactoring to really achieve that. The main use case for the first revision should be just going for open street map levels of functionality. Not even worrying about being an alternative for people with 'enterprise' workflows, just a group of people who want to collaborate on a map (put their favorite bike paths, ect.). So basically absolutely no need for branches and sandboxes and the like.
But I do agree that it's worth thinking about now, if certain decisions can make it easy to do branches and the like in the future. But don't expose them yet, just focus on the simpler use cases.
So the divide I would make for 'requirements' is:
Simple - Diff, rollback, attribution, plugins for validation (since we already have the engine) and notification. Hopefully 'checkout' in this category as well.
More advanced functionality - branches, peer review, tags.
Leave the advanced functionality off the design, except for this initial stage. So 'cvs for geospatial web', 'peer review', and 'patches' should be off the initial requirement list. (cvs for geospatial web may end up just as branding for earlier versions, even if we don't do full branches and the like). And in the extra requirements, 'object of versioning' does not need to be handled yet - the validation engine could maybe do some of this. Branches should be later. Tags could be nice this round, but I'd still hold off, as I want to get something basic out as soon as possible.
I'm not saying completely cut these requirements, just divide it up in to two sections, with the basic requirements and the advanced requirements. And hopefully our design will be able to expand for the advance stuff, but we don't need to have all the answers and to totally design it.
On the open questions, I say for now we don't even think about versioning schema changes. It gets too hard, we can refactor later in some way if it's needed. For keeping data structures untouched, I would say if we can, then we should. And if we can't we should expose it over WFS as if it is untouched.
GetFeature actually has hooks for revisions. They are not really thought out in terms of use cases.
<xsd:attribute name="featureVersion"
type="xsd:string" use="optional"/>
It's an attribute of a Query.
'The optional featureVersion attribute on the <Query> element is included in order to accommodate systems that support feature versioning. A value of ALL indicates that all versions of a feature should be fetched. Otherwise, an integer, n, can be specified to return the nth version of a feature. The version numbers start at 1, which is the oldest version. If a version value larger than the largest version number is specified, then the latest version is returned. The default action shall be for the query to return the latest version. Systems that do not support versioning can ignore the parameter and return the only version that they have. It should be noted, that if the value of the featureVersion parameter is set to ALL, the resulting XML document will contain duplicate feature identifiers and thus cannot be validated. '
It implies a more cvs style of doing things, but if we want to do something different I wouldn't be against repurposing it for our needs. But it should be noted that there are some hooks for this in the WFS spec.
For Transaction stuff, for the first round we want to modify as little as possible. So no extensions for branch/tag that we're doing the transaction against, no reporting of conflicts. If there are conflicts we can just reject it, put it in a WFS exception.
Difference handling: It sounds like copy is the easiest to implement, so I'd say start with that. Diff stuff is a whole can of worms - the approach might be to start with copy, and try out diff stuff extermally - like the 'patch' thing. Then we can experiment with the best way to do that externally, and perhaps learn those lessons and apply them internally.
Also, I'm not sure this got across in 'my' implementation vision, but I prefer a version table for each table, not a single version table for all tables in a database. Just wanted to clarify as I'm not sure it was clear.
I'm not super attached to the vision, it just seemed a way to implement it that would have nice side effects when combined with WFS.
A couple of other thoughts - speed is most important for GetFeature responses. If we're a bit slow when people do inserts/updates that's ok, it's more important that the latest revision is fast. Even if branches are a bit slower than the default, that's ok, especially for now. But yes, put some thought in to forward vs. backwards and all that, but not too long, just make a call and implement something - I imagine no matter what we'll need a re-design in the future.
best regards,
Chris
Andrea Aime wrote:
Hi all,
I've just updated quite a bit the versioning WFS page with
a slightly extented section about WFS-T protocol extension
incorporating Jody's comments, and then two new sections about
how branches and versioning itself is handled in ArcSDE and
subversion.
That's enough for today, now I'm going to chill out trying to
stomp a few other bugs in the geoserver codebase :-p (yes,
apparently we still have 1 serious problem in geoserver that
we want to fix before releasing 1.4.0).
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,455892f3202974820651628!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org