What about allowing the client to limit the number of SRSs? I'm thinking adding a parameter 1) Specifying a list of projections of interest (GeoServer would return the intersection) or 2) A numeric limit?
That way it can have as much cake as it can handle, and not change the default behavior ;) -Arne Justin Deoliveira wrote: > 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 >> >> >> >> > > > ------------------------------------------------------------------------- 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
