On Mon, Mar 9, 2009 at 3:54 PM, Justin Deoliveira <[email protected]>wrote:
> Andrea Aime wrote: > > Jody Garnett ha scritto: > > ... > >> Okay that is probably the step I was missing; with that in mind can we > >> make the decision to keep the api we publish here stable for GeoServer > >> 2.0 - even if that means we present new capabilities in GeoServer 2.0 > >> in a slightly screwed form (ie we may not get away with pure > >> reflection?). > > > > For 2.0 I believe so. But I don't have the crystal ball. > > If some significant contribution comes in, or some significant new > > functionality is sponsored, we may have to change the api. > > > > As far as I remember in the REST world one tends to "version" the > > api and try to keep at least one old version around, not sure what > > Justin's plan are on this one thought. > The api is going to undoubtedly change as we continue to change the > configuration. I have tried to hit a middle ground with the current rest > api that hits some of the concepts that we anticipate, 1) it groups by > workspace, not namespace, and 2) makes layer a separate entity when in > reality it is not, etc.. Versioning the api makes a lot of sense to me. > And when it does come to change I don't anticipate any issues with going > though a normal deprecation cycle first. Personally I don't see a huge reason to try to commit to backwards compatibility with the 1.7.x rest api and the 2.0.x rest api. Don't get me wrong, it'd be super nice. But if we are doing a major version change we do have the luxury of breaking apis if we need to. Clients should not expect that a 2.0 version of the product will have a completely backwards compatible api. Of course I do think our design of a rest api should not be tightly coupled to how we make our catalog - it should be independent concepts ideally. But realistically this is our first attempt, and though it's not bad we'll probably see how we can improve it. Since we are moving to 2.0 we do have the chance to 'throw one away', and make a really nice one for 2.0. C > > > > >> To handle the kind of structural changes you seem demanding for, we > >> need to work on trunk and change the catalog api accordingly, and we > >> need some funding to make the changes, or someone that wants to > >> spend his time working on it. > >> > >> > >> I was not aware this was pure reflection. > > > > It was figured speech, I was not implying the usage of Java reflection > > (thought it's actually used in the classes, but don't exactly know to > > which extent). > It uses reflection for serializing and deserializing catalog objects. > The rationale was 1) we already have a bunch of utilities that help us > do reflection and 2) we already had the xstream encoder/decoder which > works reflectively so using it for rest was a pretty big win to support > XML and JSON out of the box. > > > >> The topic of GSIP 33 is "is this REST api good to deal with the > >> GeoServer catalog we have today?", what you're trying to discuss is > >> "is the catalog API good for the > >> next 5 years?" which is definitely a interesting topic, but a > >> different one. > >> > >> > >> I was trying to hit the middle ground of; how do we intergrate a few > >> of tomorrows features into the api being published today. I tried to > >> make some suggestions that would agree with the plan out outlined in > >> the documentation. > > > > What makes people react negatively to your suggestion is that they > > come with request of more work and no contribution on your part. > > The idea is welcomed, but the way you're expressing it seems like > > twisting people arm into doing more work than they have resources for... > > not surprisingly you get negative reactions. > I think this may be a mis understanding of what feedback to a proposal > should be. I think most people want feedback to be concise and something > they can readily factor into a proposal, where as often your feedback is > thinking much longer term and at times off topic. > > > >> > >> Let's talk about it, but in a different thread, and then let's put > >> the result, along with an estimation, on the roadmap ideas, and see > >> if anyone is up to funding it. > >> > >> > >> I do not think we need to go that far; I just wanted to account for > >> how future work would be integrated into the api as published. I do > >> not want to publish an API we know is going to be broken in the next > >> year. > > > > Then let's stop doing anything in GeoServer. The current development > > model does not allow to account for such long term concerns. > > Release early and often does not work well with "let's account for next > > 5 years". When we're lucky it has a glimpse of what's coming in the > > next year. > > > > Just look, for example, at the roadmap ideas page. It has topic to cover > > one/two years of development. Yet none of them has direct sponsoring > > so far, so I cannot say whether they will be development in six > > months, or five years. > > > >> Or if we do I would like to know that - and be up front with script > >> writers that they will need to adjust their scripts to work with > >> GeoServer 2.0. > > > > That is certainly a concern I share. This is becoming published > > api, meaning that if we change it, we need to provide a migration > > path. Possibly going thru intermediate deprecations and replacements. > +1 > > > > Cheers > > Andrea > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
