Java projects can do that ;) If you could possibly share your scripts or simply document how to make some of the example calls in php that would be much appreciated. Currently (as you have seen) we only have examples in curl:
http://docs.geoserver.org/stable/en/user/extensions/rest/rest-config-examples.html Let me know if you are interested. -Justin On 4/13/10 10:18 AM, Tara Athan wrote: > OK, I think I'll go back to my PHP scripts, as the java project has > morphed into something way beyond my experience and time available. That > should solve my immediate needs and perhaps produce something useful to > others as a batch approach to the cURL commands. > > Thanks for all your insights, Tara > > > Justin Deoliveira wrote: >> 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 >>> >> >> >> > > > -- > Tara Athan > Owner, Athan Ecological Reconciliation Services > tara_athan at alt2is.com > 707-272-2115 (cell, preferred) > 707-485-1198 (office) > 249 W. Gobbi St. #A > Ukiah, CA 95482 > > > > ------------------------------------------------------------------------------ > 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
