Yeah, I see the point... but then how does a server that supports the entire epsg database avoid overloading a client? I mean sure maybe the browser is not the intended client for a WMS capabilities document but its not absurd to think that a client will be storing the parsed capabilities document in memory.
I guess there is no way to have your cake and eat it to... Perhaps this is something better left to be handled on a configuration basis. But the question now becomes is it more "useful" to by default tame the capabilities document to a more manageable size, or more useful to advertise every srs under the sun... I don't know the answer. I will let those smarter than I debate that one :). Paul Ramsey wrote: > I think it's a terrible idea! Firefox is not the expected client for a > OWS capabilities file, and by restricting the SRSs you advertise > you're restricting the power of your server: a client cannot request > an SRS it thinks you don't support! You have this wonderful SRS > engine behind Geoserver, that supports every SRS under the sun, don't > hide it from the world by default. > > P. > > On Wed, May 28, 2008 at 4:01 PM, Justin Deoliveira > <[EMAIL PROTECTED]> wrote: >> Hi Tim, >> >> I think your suggestion makes sense. One thing we could probably do is >> on startup check each layer for its SRS and only include those in the >> default capabilities document. If the user wants to change it after that >> they are free to do so. >> >> It would take a bit of book keeping to manage when new layers are added >> but I think it could work. >> >> Andrea, what do you think? >> >> -Justin >> >> Tim Schaub wrote: >>> Hey- >>> >>> A small exercise with my results next to each step. >>> >>> 1) Click: >>> http://sigma.openplans.org/geoserver/ows?SERVICE=WMS&REQUEST=GetCapabilities >>> (wait 3 seconds) >>> 2) Save the result to your desktop, call it ows.xml. >>> 3) Drag ows.xml into Firefox (wait 10 seconds). >>> >>> Granted, the delay in step one is largely my fault for living in the >>> boonies. I'm mostly concerned about the delay in step 3. >>> >>> A 10 second delay in a web application is enough time for me to decide >>> things are broken. This delay is what it takes the native DOM parser to >>> deal with the capabilities response - just to display the resulting >>> purple, black, and blue DOM tree. Extracting any useful information out >>> of this doc requires additional parsing time, and displaying something >>> more meaningful (than the purple, black, and blue DOM tree) requires >>> extra rendering time. >>> >>> I know folks can configure things to limit the SRS list in the >>> capabilities doc >>> (http://geoserver.org/display/GEOSDOC/Common+OWS+Configuration). My >>> question is if others think it makes sense to start out with a limited set. >>> >>> Would it be possible to have a smarter default? Seems like three >>> options for controlling SRS in capabilities would be nice: >>> >>> 1) all (current default) >>> 2) native + limited set (proposed smart default) >>> 3) limited set (current alternative to default) >>> >>> (Trimming the list down to a more reasonable 10 cuts the native parser >>> time down to a fraction of a second.) >>> >>> Thanks for any feedback. >>> Tim >>> >>> PS - I know the browser is not the client folks have in mind when >>> designing W*S specs, but it is a pretty important player in the W part. >>> >>> >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >>> >> >> -- >> Justin Deoliveira >> The Open Planning Project >> [EMAIL PROTECTED] >> >> ------------------------------------------------------------------------- >> 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 > > !DSPAM:4007,483df03212411096210785! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
