Wow, a lot to digest ;). But I think in the end I agree with you. It does not seem to be a huge win to spend a lot of time getting REST working on 1.7.x if we just have to redo a lot of it for 2.0 anyways. Especially since its just going to be something that ties us down as the api will be changing.
Cutting REST from scope for 1.7.0 would allow us to get it out the door faster and focus more time on getting 2.0 ready for prime time. The downside being a feature short for 1.7.x... which i don't think will be too bad... we still have per-layer security. My 2c. -Justin David Winslow wrote: > Hi all, > > As I'd like to be able to include RESTConfig in 1.7.0 when it comes out > I am trying to assess its current state and work out how much needs to > happen before it makes sense to consider it for inclusion. Right now it > provides configuration for datastores, coveragestores, featuretypes, > coverages, and styles. Test coverage is nil. Documentation is only what > exists on the wiki at > http://geoserver.org/display/GEOSDOC/RESTful+Configuration+API. > > The resource representations at this point are mostly auto-generated > XML/JSON with a fairly flat structure that lines up pretty closely with > the Struts configuration pages. This will lose some intuitiveness when > the new UI is released, but that won't be a problem in the timeframe of > the 1.7.x series. The configuration model is going to change pretty > drastically for 2.0, however, so if the API is released as is any code > based on it will be broken for 2.0. That's probably "okay" for a major > release, but it seems kind of unpleasant for clients to have an API > released as 'supported' and then completely rearranged a few months later. > > (Sidetrack: What's so different about the new configuration system? We > now have lots of neat things like different backends, easier > extensibility, a distinction between a published Layer and a server-side > Resource. Of these, only the Layer/Resource distinction poses a real > problem, since choosing a backend should be a one-time operation (and > anyway, being able to switch from a high-performance database-backed > configuration persistence mechanism to a verbose XML format remotely > sounds more like a DoS vulnerability than a feature to me), and we can > just ignore configuration options provided by extensions (although > 'extensions as first-class citizens of the configuration system' would > be a nice feature). But the Layer/Resource schism means that a number > of options that are currently lumped into a 'layer' as exposed by the > current RESTConfig implementation would need to be separated. One > alternative is to continue to use the current API and just expose one > layer for each publishe layer, and silently sync up changes made to the > settings there that are actually on the data side of things. But this > is (a) icky and (b) doesn't allow configuring datastores remotely (since > we'd need to exposed the layers as grouped by workspace) A better > option would be to have /data and /publish hierarchies in the REST API > for 1.7.0... but it doesn't seem like this is a great option either > since we already have a project underway to line up the 1.6.x and 1.7.x > versions of the REST API, indicating that we have at least one client > for whom this would break compatibility.) > > Okay. Given all of this it seems that there is a fair bit of work to do > before RESTConfig is ready for primetime. > * Nail down the resource layout... I think what's there now (in 1.7.x) > will stay (for 1.7.x); the question is whether or not any of the > unimplemented features should go in. I suspect automated configuration > of coordinate reference systems and layergroups are of limited utility > in comparison to mass shapefile uploads, but I'm a bit out of my element > when it comes to envisioning RESTConfig use cases. > * Document the representation formats. This is a bit more important now > that RESTConfig obscures the difference between FeatureTypes and > Coverages since the representations are not uniform at the same location > in the hierarchy. > * Get some test coverage in there! I've been waffling a bit on this > trying to figure out how best to build the tests as a reusable client > library; but at this point I think it's best to just write some tests > (and not have to wonder whether the failures are due to bugs in the > client or the server). > > Since RESTConfig doesn't seem likely to be stable (in the reliably > unchanging behavior sense, not the non-buggy sense) over the next > months, I wonder whether it is useful to include it in 1.7.x releases > after all; maybe it should just stay in community until 2.0.x. > > -David Winslow > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > !DSPAM:4007,4862c78676581431913854! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
