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
