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
