Hi all,
here is the latest GSIP about URL building and mangling.
http://geoserver.org/display/GEOS/GSIP+39+-+Centralized%2C+pluggable+URL+mangling
It follows up the discussion about "URL construction callbacks" we had
in the past days on this mailing list.
Discuss and vote please 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Hi all,
here is the latest GSIP about URL building and mangling.
http://geoserver.org/display/GEOS/GSIP+39+-+Centralized%2C+pluggable+URL+manglingIt follows up the discussion about "URL construction callbacks" we had
in the past days on this mailing list.Discuss and vote please
Cheers
Andrea
Sort of an orthogonal issue, but how do we specify the base URL ?
Multi-homed GeoServers, which will become more of an issue when people start using the concept of workspaces, will need to support several base URLs for the same instance.
One example would be to pass in ..&BASE_URL=... as a replacement for "http://hostname:port/context" when you make a getcapabilities request
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Arne Kepp ha scritto:
Andrea Aime wrote:
Hi all,
here is the latest GSIP about URL building and mangling.
http://geoserver.org/display/GEOS/GSIP+39+-+Centralized%2C+pluggable+URL+manglingIt follows up the discussion about "URL construction callbacks" we had
in the past days on this mailing list.Discuss and vote please
Cheers
Andrea
Sort of an orthogonal issue, but how do we specify the base URL ?
We get it from the current request, it's happening in the Dispatcher,
line 458 (on trunk).
Multi-homed GeoServers, which will become more of an issue when people start using the concept of workspaces, will need to support several base URLs for the same instance.
The base URL I'm talking about there is really just the equivalent
of "http://host:port/geoserver", that "root" part should be there
even after the resource/publish split
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Arne Kepp ha scritto:
<snip>
Sort of an orthogonal issue, but how do we specify the base URL ?
We get it from the current request, it's happening in the Dispatcher,
line 458 (on trunk).
That should work, at worst they have to mess with /etc/hosts on the proxying server.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
One thing i just thought of is mangling that has to occur dynamically. Perhaps based on a request parameter. Currently by using only string registered url manglers it seems that urls could only really be mangled staticaly.
Anyways, not a -1 or anything, just a thought. And probably something that could be solved by simply overloading buildURL() to take a URLMangler as an optional parameter.
Also, in terms of naming i think URLMangler.mangleUrl should change to mangleURL() to match buildURL().
Updated GSIP with a +1 vote.
-Justin
Andrea Aime wrote:
Hi all,
here is the latest GSIP about URL building and mangling.
http://geoserver.org/display/GEOS/GSIP+39+-+Centralized%2C+pluggable+URL+manglingIt follows up the discussion about "URL construction callbacks" we had
in the past days on this mailing list.Discuss and vote please
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
One thing i just thought of is mangling that has to occur dynamically. Perhaps based on a request parameter. Currently by using only string registered url manglers it seems that urls could only really be mangled staticaly.
Anyways, not a -1 or anything, just a thought. And probably something that could be solved by simply overloading buildURL() to take a URLMangler as an optional parameter.
What is the use case of passing a custom mangler besides the one
already registered in the spring context?
Also, in terms of naming i think URLMangler.mangleUrl should change to mangleURL() to match buildURL().
Right.
Updated GSIP with a +1 vote.
Thanks
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
One thing i just thought of is mangling that has to occur dynamically. Perhaps based on a request parameter. Currently by using only string registered url manglers it seems that urls could only really be mangled staticaly.
Anyways, not a -1 or anything, just a thought. And probably something that could be solved by simply overloading buildURL() to take a URLMangler as an optional parameter.
What is the use case of passing a custom mangler besides the one
already registered in the spring context?
I guess I don't have one really. Just thought that a mangler registered in a spring context will be relatively static, and not have access to dynamic info like request parameters, etc...
It also might be a bit cleaner to have service code explicitly invoke a mangler in a conditional case, rather than have the mangler registered, and have it check that case. And in that case the mangler might not have the relevant information to check the condition. Like maybe its perhaps something that based on the value of a format option.
Anyways, probably something best tabled for now, and we can revisit it if it does indeed turn out to be a limitation.
Also, in terms of naming i think URLMangler.mangleUrl should change to mangleURL() to match buildURL().
Right.
Updated GSIP with a +1 vote.
Thanks
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.