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. > >> 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
