>
> Jody,
> the problem I'm seeing here is that you're trying to comment on
> too much at the same time.
You are no doubt correct; I was trying to gauge our commitment to the api we
are publishing here.
One thing is the technical means we're using to present the
> configuration, and the other is the configuration itself.
> The two are in fact tightly connected, as the REST api is a
> pure reflection of the catalog API of GeoServer, but we
> cannot work on both of them at the same time, especially
> not on 1.7.x where the catalog API is mostly frozen.
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?).
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.
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.
> 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.
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.
Jody
------------------------------------------------------------------------------
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
