Hmmm... i would say this is a different issue all together. How to handle changes to the core configuration model (and consequently the representations of resources in the rest api) seems a bit different than having a client being able to round trip all information working against a single version.
I do like the idea of having version information in the header and encouraging clients to specify versions of the api they know are supported. On 4/13/10 9:37 AM, David Winslow wrote: > Actually, it seems the shared-model-object approach would be subject to > the same issues described in this thread, if you mismatched versions of > the rest client and the rest service. This would make it tough for > distributers of tools based on the RESTConfig service. I guess an easy > fix would be to add some versioning info (like a > 'X-GeoServer-REST-Version: 2.0.1' HTTP header or a '?v=2.0.1' query > parameter) to each request and have the service refuse to handle > transactions that mismatched in version. This would just make the > mismatch less destructive, though. > > I think in the end, client implementers will do best by modifying a dom > (or a nested map structure if they are working against JSON) and simply > preserving unrecognized entities. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 04/13/2010 11:25 AM, Justin Deoliveira wrote: >> Hi Tara, >> >> First off there was never a schema published for the rest configuration >> api. The author (Ronak) I believe generated one on his own. There was >> some discussion on the list about whether to generate a schema or not. >> >> But yes your findings sound reasonable and I like the approach (only >> changing what you care about and preserving the rest). At the same time >> I also see the case for a stable schema for developers to write against. >> Tough call. >> >> There is actually talk currently going on to factor out some of the >> geoserver internals into a reusable client module. This would give java >> clients the same object model that we use internally in geoserver. The >> real benefit would be that all the XML marshaling/unmarshalling that >> exists in Geoserver today could be reused by the client. This is still a >> little far off though. But would probably be the most robust way to >> build a java restconfig client. I like the DOM approach though as you >> propose. It is nice and simple. >> >> 2 cents. >> >> -Justin >> >> On 4/12/10 10:10 AM, Tara Athan wrote: >> >>> I have been looking at the restconfig-java code... I had hoped there >>> would be an easy temporary fix for all the missing parts that would just >>> leave the missing parts unchanged, but the way the code is set up I do >>> not see any easy way to do that. This is because it uses "@Xml..." >>> annotations from the javax.xml.bind.annotation package to translate the >>> xml into java objects, uses mutate methods to change things and then >>> translates back to xml. So the code needs to be fixed to have all xml >>> elements properly translated so that it doesn't wipe them out. >>> >>> I am wondering if this is a reasonable approach- unless the Rest schema >>> is very stable, this code will have to be carefully updated anytime >>> something new is added to the schema, or it will cause these new >>> elements to be wiped. >>> >>> I am guessing this is what happend with the current code- it looks like >>> the author wrote it to correspond to a different xml schema, and then >>> the schema changed. Actually now that I know how it is supposed to >>> work, I am reluctant to fix it, because then it becomes dangerous if the >>> Rest schema changes, unless there are checks that will verify that the >>> complete xml element was translated and shut down before any harm is done. >>> >>> Before I heard of the restconfig-java module, I was working on some PHP >>> that would download the xml into an object, change certain things, leave >>> everything else the same and then upload. I think a similar approach >>> would work in java using the DOM API. Although this is not as slick as >>> using the @Xml annotations, it seems more robust to me. >>> >>> Comments are appreciated, >>> Tara >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Geoserver-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
