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. > 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). > 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. > > 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. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
