Hi guys,
I almost agree with you David, and also I think RESTConfig should not be
included into 1.7.x release at least in this very incomplete state, but
anyway it is a valid alternative to interact with GS catalog configuration
... so what I'm thinking is that maybe we can distribute it as a GeoServer
1.7.x extension or something like that. Does it make sense?
On Thu, Jun 26, 2008 at 2:01 AM, Justin Deoliveira <[EMAIL PROTECTED]>
wrote:
> 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
>
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
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
