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
