I actually think namespaces are a very cool idea in geoserver. They allow a common back-end data "structuring" that allows different blocks of data to have the same type name without conflicting.
Also, the wmsPath (as I understand it) doesn't really have much to do with namespaces. It's about mapping wms layers into the (imho confused) wms layer "tree". Am I confusing that wmsPath with a a different one (the one on the UI?) Either way, I'm definitely +1 for keeping namespaces around! --saul On Wed, 2008-03-19 at 10:11 -0700, Justin Deoliveira wrote: > Let me state my rationale, should have in the first email. I think that > as GeoServer moves toward restful services, the need to reference layers > or resources without a namespace prefix is going to increase. And we > will see layers showing up in url's. Like for geosync: > > http://geoserver.../history/states/changes > > Having to do: > > http://geoserver.../history/topp:states/changes > > is a bit strange. I know in this case states in usually in the default > namespace but that is really besides the point. > > Also, with the new config model we have a chance to make namespaces less > prevalent. I see them as being something that should only apply to WFS. > Having the notion of a namespace in WMS is something that people > continually have trouble with. The result has been us developing things > like "wmsPath", which is kind of a band aid solution in my opinion. > > Anyways... the point is that I think we are going to have to deal with > this at sometime. Regardless, you bring up a good point Andrea, about > confusing results with multiple layers in different namespaces. I think > in the least we should add a meaningful exception for the case when > there are multiple, and that user has not used a prefix. > > My 2c. I am eager to hear others thoughts on this. > > -Justin > > > > > > Hum, I had a look at the patch and it seems ok code wise. The usual > > steps are followed anyways: > > * try a full match > > * try adding the default namespace prefix in front of the name > > > > and then the full match by name is tried. Yet, I'm not sure I > > understand why we need to match the unprefixed names out of the > > default namespace... that is, we never had this behaviour. > > > > It this patch related to http://jira.codehaus.org/browse/GEOS-1816? > > In that case the layer name was states, so prefixing it with > > the default namespace should have done the trick? > > > > I'm just trying to understand what's the use case for this. > > Think of the consequences. You have a certain feature type "XX" > > in a non default namespace, you make an unprefixed request, > > you get back data. Then you add another "XX" in a different namespace > > and boom, the previous request stops working because now you have two > > (the patch returns a feature type only if it can find one instance). > > Or you add a new "XX" to the default namespace, and you start getting > > back completely different data (since the one in the default namespace > > is looked up before the unprefixed match attempt). > > > > Yet, you can get a similar mess with the old code as well, you just have > > to change the default namespace and all your unprefixed queries go bye > > bye. Yet it seems to me the patch might increase this confusing behaviour. > > > > Opinions? > > Cheers > > Andrea > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Geoserver-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > !DSPAM:4007,47e0d98f299621431913854! > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
