I have been following the wfs simple discussions and like the focus on usability by mere mortals. However I have to agree with Chris with that transactions by nature are non-simple. But Andrea's approach to versioning follows the KISS philosophy so I remain optimistic that the two will be compatible in some shape or form.
-Justin Chris Holmes wrote: > > > Jo Walsh wrote: >> dear Justin, all, >> On Mon, Nov 27, 2006 at 11:45:24AM -0800, Justin Deoliveira wrote: >>> Considering that not many people implement wfs altogether, I dont think >>> a ton of people will implement wfs-t. I agree that a simple protocol is >>> a big win, but not if it starts to reek havoc with existing clients. >> >> Have you considered WFS transaction and versioning over WFS Simple? >> http://www.ogcnetwork.net/wfssimple > > We're definitely following WFS simple stuff there closely. Ok, Justin > is, I left the week where it really took off and haven't caught up. But > have there been any thoughts thus far to transactions? In the past I've > wondered about Atom publishing protocol as an alternative to WFS-T... > > I do think/hope our implementation is compatible with things in simple. > So you'd be able to use simple to get the latest features, and you > could use simple to get the changesets as well (since it's just a table > that we can expose as WFS). > > I would love it if we could include our ideas on transactions and > versioning and the like in WFS-Simple, but unfortunately I do fear that > when you get in to transactions, authentication, and versioning you're > no longer in 'simple' land (indeed I myself might argue against their > place in a simple spec). > > Nothing we are doing is incompatible with simple, but most of what we're > doing is on transactions and newer stuff (diffs and rollbacks)). > >> >> WFS Simple is designed to have a lot more appeal to casual >> implementors. OpenStreetmap.org is one project that's been WFS-T >> curious for awhile >> but found the spec overhead combined with the lack of versioning / >> history support, unappealing. But they would benefit hugely from >> being able to plug into more generic drawing client support than their >> current interface allows ( http://wiki.openstreetmap.org/index.php/REST ) > > Yeah, that's definitely one of our goals, to be something that OSM could > use to plug in to more generic clients. Indeed I had Andrea check out > their API today. When the simple spec settles we're definitely hoping > to include it in GeoServer (and I think one of Stefan's students was > going to look into an implementation, based at least partially on > GeoServer - I need to follow up on the status). > >> >> While the apogee for a specification is inclusion in geoserver or >> mapserver, it would be great if what came out of the geoserver WFS-TV >> efforts *was* appealing to and implementable by a ton of people... > > We definitely hope so too, and want to encourage people to look over > what we're doing to help make it more accessible. I'm definitely open > to a REST API that works against the same backend, if that's what's > needed for 'easy'. Right now we're just extending WFS-T, since there > are clients that implement it already, as opposed to something we just > invent, which may not. We'll try to write up exactly what the protocol > will look like, if you know WFS you can check out our proposal at: > http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal > (I just read it and unfortunately it does make assumptions about knowing > how WFS works - sorry, as we tighten up and get an implementation we'll > definitely make a document of how to do version stuff with no advance > knowledge of WFS). > > Again though, versioning done right is kind of a complicated thing. > We're trying making it as easy as possible. But if you have feedback to > help us on making it even easier, we're all ears, for sure. Perhaps WFS > Simple first needs to define what a simple transaction is, make a better > interface than the current WFS, and then we can build versioning on top > of that? Though I have maintained that the Transaction portion of the > spec is actually quite nice - maybe 'Simple' could just make it so it > doesn't stress about namespace and gml validation and all... > > best regards, > > Chris > > >> >> cheers, >> >> >> jo >> >> ------------------------------------------------------------------------- >> 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 >> >> >> > > ------------------------------------------------------------------------- > 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 > > !DSPAM:1004,456b76ed301421804284693! > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > !DSPAM:1004,456b76ed301421804284693! -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
