Has not been forward ported from 1.7.x yet. The reason being that when i moved RESTConfig from community to extension i rewrote it against the new catalog api. Since that api has been under flux lately I have been putting off porting the restconfig extension to trunk. But plan to do so soon.
-Justin Simone Giannecchini wrote: > Ciao Justin, > just out of curiosity, what's the situation with rest and restconfig on trunk? > > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Owner - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://simboss.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > > ------------------------------------------------------- > > > > On Fri, May 8, 2009 at 6:40 PM, Justin Deoliveira <[email protected]> > wrote: >> Well actually thinking about it, the old RESTConfig community module is >> still there, and all the classes are there pre-change. So you may just be >> able to use it. >> >> My only hesitation is that we will end up in this same situation, a bunch of >> work will be done there and it will not be ported properly back to the >> extension. But since you guys are on a tight deadline we don't have much >> choice. >> >> So proceed as you see fit, either create a new community module or use the >> existing RESTConfig one. >> >> -Justin >> >> Daniele Romagnoli wrote: >>> Hi, >>> while waiting for an improved catalog, as a quick workaround we could set >>> up a community module which is a "copy" of the actual restconfig extension >>> containing the workarounds. >>> (let's say, something similar to a branch, but restricted to a single >>> module). >>> >>> Does this sounds ok? >>> Daniele >>> >>> >>> >>> On Fri, May 8, 2009 at 6:16 PM, Simone Giannecchini >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Ciao Justin, >>> please, see below... >>> >>> >>> On Fri, May 8, 2009 at 6:10 PM, Justin Deoliveira >>> <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > >>> > Simone Giannecchini wrote: >>> >> >>> >> Actually, >>> >> yeah, I have one objection. >>> >> Beside the fact that I am not so convinced that separating the two >>> >> calls will make the api cleaner, >>> > >>> > I would argue it does from a REST perspective. Any parameters >>> that modify >>> > the resource being PUT should be in the request entity, not in >>> the URI that >>> > defines the resource. >>> > >>> > I am quite worried that this would >>> >> >>> >> make the whole process much weaker. In the real world, when you >>> want >>> >> to add data in a dynamic way with a heavily loaded server with the >>> >> current geoserver internal catalog it is not uncommon that >>> everything >>> >> breaks due to the fact that it takes quite some time to persiste >>> the >>> >> changes. You understand that starting to explode the number of >>> calls >>> >> to configure a single layer will not work in real use cases. >>> > >>> > I understand the issue, but I hope you can understand why I am >>> hesitant to >>> > make API compromises to get around limitations which are >>> currently just an >>> > implementation detail. Like if we had a catalog that performed >>> well under >>> > update this would be an non issue. >>> > >>> >>> I agree, but we don't have such a catalog yet :-). >>> >>> > Even in 2.0 this should be much less of an issue since now the >>> only thing >>> > that gets saved is what you modify. Should be much more >>> performant under >>> > heavy update load. That said I do realize that you are working >>> with 1.7.x >>> > and need to work stable. >>> > >>> > Putting the issue of the current catalog aside for the moment, I >>> would >>> > speculate that the cost of a second call should be negligible >>> compared to >>> > the first. The reason being that since the first request involves >>> a data >>> > upload it could potentially take a while assuming a decently >>> sized dataset. >>> > But the second call should always be constant time. So you have 1 >>> > potentially long request + 1 constant time (instantaneous when we >>> have a >>> > decent catalog). >>> > >>> >>> I am talking about a different thing. >>> If you have 2000 coveragerages configured it takes a non negligible >>> time to persist the config. >>> Do it twice is simply not acceptable. >>> >>> >>> >>> > That said, I would like to come up with a compromise here, and I >>> would like >>> > to do so in a way that does not prevent you from meeting any >>> deadlines. >>> > Since the rest system is pluggable can we move the code that >>> contains these >>> > workarounds for our current catalog limitations into a community >>> module. >>> > Doing so allows us to have a way to achieve the desired >>> functionality for >>> > now, but at the same time does not tie us to it for future >>> versions. And >>> > with a little spring magic we should be able to do in a way that the >>> > community module version overrides the extension version so there >>> are no URI >>> > conflicts. >>> >>> I'll live that to daniele, since we already modifying code that worked >>> before 1.7.3, therefore there is not much time available for more >>> work. >>> >>> Simone. >>> > >>> > Thoughts? >>> >> >>> >> >>> >> Simone. >>> >> ------------------------------------------------------- >>> >> Ing. Simone Giannecchini >>> >> GeoSolutions S.A.S. >>> >> Owner - Software Engineer >>> >> Via Carignoni 51 >>> >> 55041 Camaiore (LU) >>> >> Italy >>> >> >>> >> phone: +39 0584983027 >>> >> fax: +39 0584983027 >>> >> mob: +39 333 8128928 >>> >> >>> >> >>> >> http://www.geo-solutions.it >>> >> http://simboss.blogspot.com/ >>> >> http://www.linkedin.com/in/simonegiannecchini >>> >> >>> >> ------------------------------------------------------- >>> >> >>> >> >>> >> >>> >> On Fri, May 8, 2009 at 5:25 PM, Justin Deoliveira >>> <[email protected] <mailto:[email protected]>> >>> >> wrote: >>> >>> >>> >>> For the first patch: >>> >>> >>> >>> + final LayerInfo layerInfo; >>> >>> + final Map<String,String> layerProperties = new >>> >>> HashMap<String,String>(2); >>> >>> + if (form.getFirst("style") != null) >>> >>> + layerProperties.put("style", >>> >>> form.getFirstValue("style")); >>> >>> + if (form.getFirst("wmspath") != null) >>> >>> + layerProperties.put("path", >>> >>> form.getFirstValue("wmspath")); >>> >>> + if (layerProperties.isEmpty()) >>> >>> + layerInfo = builder.buildLayer(cinfo); >>> >>> + else >>> >>> + layerInfo = >>> >>> builder.buildLayer(cinfo,layerProperties); >>> >>> + catalog.add(layerInfo); >>> >>> >>> >>> I think this should be handled with a second call, rather than >>> stack up >>> >>> available options. It makes the api cleaner imo. And is less >>> arbitrary. >>> >>> For instance why do we support style and wms path but not the >>> other >>> >>> properties? >>> >>> >>> >>> So I would prefer the interaction to be: >>> >>> >>> >>> 1) PUT to upload the coverage >>> >>> 2) PUT to modify the coverage >>> >>> >>> >>> Objections? >>> >>> >>> >>> Daniele Romagnoli wrote: >>> >>>> >>> >>>> Hi Justin, >>> >>>> I'm really sorry about this. >>> >>>> Next time I'll follows the steps you are talking about. >>> >>>> I was working on the coverages ingestion and I needed to >>> re-enable some >>> >>>> capabilities available in 1.7.2 for an urgent application. >>> >>>> I was too hasty. Sorry again. >>> >>>> >>> >>>> >>> >>>> On Fri, May 8, 2009 at 4:22 PM, Justin Deoliveira >>> <[email protected] <mailto:[email protected]> >>> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>> >>>> >>> >>>> Reviewing the commits more closely I definitely have a few >>> concerns >>> >>>> which affirms my preference to have these changes reviewed >>> before >>> >>>> hand. >>> >>>> >>> >>>> * The method added to catalog builder seems unnecessary to >>> me. I >>> >>>> think >>> >>>> just the plain buildLayer can be called, and then properties >>> >>>> overrideen >>> >>>> after the fact, instead put putting them into a map and >>> passing it >>> >>>> into >>> >>>> the method. It also does not sync up with any of the other >>> methods in >>> >>>> that class. I would like to keep that class as consistent as >>> >>>> possible. >>> >>>> >>> >>>> * You have made changes to api without any discussion. >>> Supporting >>> >>>> wmspath and and style as query parameters is not documented >>> as api >>> >>>> options: >>> >>>> >>> >>>> >>> >>>> >>> >>> http://gridlock.openplans.org/geoserver/1.7.x/doc/user/extensions/rest/rest-config-api.html#coverage-stores >>> >>>> >>> >>>> >>> >>>> The previous RESTConfig allowed to handle them. I had tought >>> during >>> >>>> migration to extensions they have been forgotten. >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> <http://gridlock.openplans.org/geoserver/1.7.x/doc/user/extensions/rest/rest-config-api.html#coverage-stores> >>> >>>> >>> >>>> Not saying we should not have them, but this is an >>> extension now, not >>> >>>> a >>> >>>> community module anymore, such things require discussion >>> before hand. >>> >>>> >>> >>>> >>> >>>> You are Right. >>> >>>> >>> >>>> >>> >>>> >>> >>>> * Many of the changes seem a bit arbitrary, changing variable >>> >>>> declarations to final for instance. Again, for consistency >>> sake I >>> >>>> prefer >>> >>>> that you delegate to how the rest of the class / method >>> does things >>> >>>> when >>> >>>> making chagnes. >>> >>>> >>> >>>> * Setting the layer name as the entity is again an api >>> change, and >>> >>>> one I >>> >>>> don't agree with. It is more RESTful to set the location of >>> the >>> >>>> resource >>> >>>> using the appropriate HTTP header, 'Location' like we do >>> for the POST >>> >>>> case. Also, the indication of where the resource should be >>> down with >>> >>>> a >>> >>>> full uri, just returning the name assumes that URI's are >>> non-opaque, >>> >>>> ie >>> >>>> the client has pre-knowledge of how URI's are built, which >>> is another >>> >>>> REST nono. >>> >>>> >>> >>>> >>> >>>> Do you think it would be better if I revert my changes? >>> >>>> Daniele >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -Justin >>> >>>> >>> >>>> Justin Deoliveira wrote: >>> >>>> > Hi Daniele, >>> >>>> > >>> >>>> > I see you are making commits on 1.7.x to restconfig and >>> main. I >>> >>>> would >>> >>>> > appreciate posting patches for pre review first before >>> committing. >>> >>>> > Especially in this case where we have not yet wrapped up >>> >>>> discussion >>> >>>> > about how to handle the PUT issue from previous email. >>> >>>> > >>> >>>> > I am not trying to hamper work here but I have been >>> deemed the >>> >>>> > maintainer of that extension, and while there are no >>> hard rules >>> >>>> in place >>> >>>> > about who is allowed to commit, i would appreciate being >>> to review >>> >>>> > commits before they go through. >>> >>>> > >>> >>>> > -Justin >>> >>>> > >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Justin Deoliveira >>> >>>> OpenGeo - http://opengeo.org >>> >>>> Enterprise support for open source geospatial. >>> >>>> >>> >>>> >>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>>> The NEW KODAK i700 Series Scanners deliver under ANY >>> circumstances! >>> >>>> Your >>> >>>> production scanning environment may not be a perfect world >>> - but >>> >>>> thanks to >>> >>>> Kodak, there's a perfect scanner to get the job done! With >>> the NEW >>> >>>> KODAK i700 >>> >>>> Series Scanner you'll get full speed at 300 dpi even with >>> all image >>> >>>> processing features enabled. http://p.sf.net/sfu/kodak-com >>> >>>> _______________________________________________ >>> >>>> Geoserver-devel mailing list >>> >>>> [email protected] >>> <mailto:[email protected]> >>> >>>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> ------------------------------------------------------- >>> >>>> Eng. Daniele Romagnoli >>> >>>> Software Engineer >>> >>>> >>> >>>> GeoSolutions S.A.S. >>> >>>> Via Carignoni 51 >>> >>>> 55041 Camaiore (LU) >>> >>>> Italy >>> >>>> >>> >>>> phone: +39 0584983027 >>> >>>> fax: +39 0584983027 >>> >>>> mob: +39 328 0559267 >>> >>>> >>> >>>> >>> >>>> http://www.geo-solutions.it >>> >>>> >>> >>>> ------------------------------------------------------- >>> >>>> >>> >>>> >>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>>> The NEW KODAK i700 Series Scanners deliver under ANY >>> circumstances! Your >>> >>>> production scanning environment may not be a perfect world - >>> but thanks >>> >>>> to >>> >>>> Kodak, there's a perfect scanner to get the job done! With the >>> NEW KODAK >>> >>>> i700 >>> >>>> Series Scanner you'll get full speed at 300 dpi even with all >>> image >>> >>>> processing features enabled. http://p.sf.net/sfu/kodak-com >>> >>>> >>> >>>> >>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Geoserver-devel mailing list >>> >>>> [email protected] >>> <mailto:[email protected]> >>> >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>> >>> >>> -- >>> >>> Justin Deoliveira >>> >>> OpenGeo - http://opengeo.org >>> >>> Enterprise support for open source geospatial. >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> The NEW KODAK i700 Series Scanners deliver under ANY >>> circumstances! Your >>> >>> production scanning environment may not be a perfect world - >>> but thanks >>> >>> to >>> >>> Kodak, there's a perfect scanner to get the job done! With the >>> NEW KODAK >>> >>> i700 >>> >>> Series Scanner you'll get full speed at 300 dpi even with all >>> image >>> >>> processing features enabled. http://p.sf.net/sfu/kodak-com >>> >>> _______________________________________________ >>> >>> Geoserver-devel mailing list >>> >>> [email protected] >>> <mailto:[email protected]> >>> >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>> >>> > >>> > >>> > -- >>> > Justin Deoliveira >>> > OpenGeo - http://opengeo.org >>> > Enterprise support for open source geospatial. >>> > >>> >>> >>> >>> >>> -- >>> ------------------------------------------------------- >>> Eng. Daniele Romagnoli >>> Software Engineer >>> >>> GeoSolutions S.A.S. >>> Via Carignoni 51 >>> 55041 Camaiore (LU) >>> Italy >>> >>> phone: +39 0584983027 >>> fax: +39 0584983027 >>> mob: +39 328 0559267 >>> >>> >>> http://www.geo-solutions.it >>> >>> ------------------------------------------------------- >>> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
