On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwins...@opengeo.org>wrote:
> Apologies for both the low code quality and the late timing, this code was > kind of a back-burner experiment. I would like to get it into RC1 however > and can put some more serious effort into it this week. > Great. But just be warned that this will be changes to core code. And last week we pushed back RC1 to accomodate some core security changes. The concerns raised there will probably be apply here in that it seems risky to make a bunch of core changes and then stamp it RC1 directly after. However I imagine the scale of these changes to be smaller so I guess we can discuss that when we have a patch in hand. > > I gather the design should be something along the lines of: > > - CatalogImpl::validate becomes public API (moving to > Catalog::validate) > - The validation code I added in ResourceInfoImpl moves to > CatalogImpl::validate(ResourceInfo, boolean) > > One question comes to mind: would it be worthwhile to make this an > extension point (for example, the style requirement would only be enforced > if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are > pretty well baked-in to the catalog so perhaps it wouldn't be useful. > > Big +1. I think an extension point makes a lot of sense and indeed something that came up in the past. It also gives smaller extensions that store metadata on catalog entries a chance for validation. > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira > <jdeol...@opengeo.org>wrote: > >> >> On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwins...@opengeo.org>wrote: >> >>> Upload to existing datastores sounds pretty useful to me... I notice the >>> example only mentions the .../file.shp endpoint; will url.shp and >>> external.shp also be supported? >>> >> >> Yup, url and external are supported as well. >> >>> >>> I have also been working on some improvements to RESTConfig - with >>> respect to error handling. The motivation is that in GeoNode we don't do a >>> lot of validation on shapefiles before passing them along to GeoServer, >>> figuring that our validation won't necessarily match GeoServer's anyway. If >>> the import fails somehow (most often due to a missing/unrecognized PRJ file) >>> then the layer is enabled anyway, and GeoServer's WMS capabilities document >>> fails after that. (We currently have some fairly kludgy code that runs >>> after such uploads to try and clean up.) >>> >>> I think it would be better if the RESTConfig importer would disable a >>> layer if it doesn't have all the required fields for continuing WMS (and >>> WFS/WCS/etc) service. I've done some work on it for WMS already (though I >>> am sure some refactoring is in order.) Diff is at >>> https://github.com/dwins/geoserver/compare/master...dont_break_wms_via_rest(and >>> if you want an actual diff file, just add .diff to the end of the URL). >>> >> >> I agree that indeed disabling the layer if it is invalid makes sense. As >> for the patch I think it needs some work. For one all the existing >> validation lives in the catalog itself, so it would be nice to keep it there >> rather than in the catalog info classes which by design we try to keep as >> "dumb" as possible. >> >> Currently CatalogImpl has a set of "validate" methods it uses for internal >> validation. There was talk before about making them actually part of the >> Catalog interface and make them actual api. This strengthens that case. >> >> Anyways, while I am all for the changes I think some more work still needs >> to be done before this gets in. And as it will probably require core changes >> I am tempted to push it off until after RC1. Although if David has time to >> put into this I will do my best to help it along. >> >>> >>> -- >>> David Winslow >>> OpenGeo - http://opengeo.org/ >>> >>> On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime < >>> andrea.a...@geo-solutions.it> wrote: >>> >>>> On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeol...@opengeo.org> >>>> wrote: >>>> > Hi all, >>>> > With the pushing back of RC1 by a week I could not help myself to whip >>>> up >>>> > two pending proposals having to do with restconfig. >>>> > >>>> http://geoserver.org/display/GEOS/GSIP+59+-+Promote+RESTConfig+to+Core+Module >>>> > >>>> http://geoserver.org/display/GEOS/GSIP+58+-+RESTConfig+API+Improvements >>>> > >>>> > The first I don't imagine will require too much discussion and >>>> actually has >>>> > already been more or less agreed upon by devs. It is the promoting of >>>> > RESTConfig to core module. It is pretty low risk so I don't forsee >>>> much >>>> > resistance to getting it into RC1. >>>> >>>> Little resistance? Ha, power up your lightsaber and face me then! >>>> (kidding, of course +1 to get restconfig into core) >>>> >>>> > GSIP 58 though probably requires more discussion. Although it was >>>> discussed >>>> > in this previous email thread: >>>> > http://old.nabble.com/some-restconfig-improvements-td30202559.html >>>> > The outcome of that proposal was two fold: >>>> > 1. It would be good to somehow share code or merge this with the wps >>>> import >>>> > functionality. >>>> > 2. Some concerns about this functionality continuing down the rest >>>> good >>>> > practice violation path >>>> > Both good concerns. For (1) I would like to push off as a future >>>> > improvement. I have some ideas about how to factor out such code but >>>> it >>>> > would be a significant under taking. >>>> > For (2) I think it was agreed that fixing these mal practices will >>>> have to >>>> > be something done in a version 2 of the api in which we can break some >>>> of >>>> > the api. >>>> > As for getting GSIP 58 into RC1 or even 2.1.0 I am not going to push >>>> on >>>> > that, i want to hear peoples opinions on that. On the one hand I want >>>> to >>>> > push for more modest development which means holding back on features >>>> like >>>> > this. On the other hand since its a public api addition it would be >>>> good to >>>> > get it into 2.1.0. >>>> >>>> Works for me, +1 on this one as well >>>> >>>> Cheers >>>> Andrea >>>> >>>> -- >>>> Ing. Andrea Aime >>>> Technical Lead >>>> >>>> GeoSolutions S.A.S. >>>> Via Poggio alle Viti 1187 >>>> 55054 Massarosa (LU) >>>> Italy >>>> >>>> phone: +39 0584962313 >>>> fax: +39 0584962313 >>>> >>>> http://www.geo-solutions.it >>>> http://geo-solutions.blogspot.com/ >>>> http://www.linkedin.com/in/andreaaime >>>> http://twitter.com/geowolf >>>> >>>> ----------------------------------------------------- >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Gaining the trust of online customers is vital for the success of any >>>> company >>>> that requires sensitive data to be transmitted over the Web. Learn how >>>> to >>>> best implement a security strategy that keeps consumers' information >>>> secure >>>> and instills the confidence they need to proceed with transactions. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> Geoserver-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >>> >>> >> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
