Hey-
Andrea Aime wrote:
Tim Schaub ha scritto:
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)
Hum, how curious. I've tested the same, and for me it takes between 1
and 2. Checked the response headers, and the file has been gzipped,
content lenght is "only" 19kb. 3 seconds to grab 19kb seems like
a long time to me.
Yeah, ignore this. It was hailing heavily and I was counting on my fingers.
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.
I guess the main problem here is that the server does not know what it
is serving data to. Is the client limited capabilities (browser), plain
stupid (arcgis < 9.3) or ok (udig)? There is no way to know in advance.
Whatever preset we choose on the server side is going to be sub-optimal
for some clients out there.
Since we have a human in the middle (either as the programmer that sets
up the connection to a well known server, or as the user that pastes
the capabilities) we could provide him with options, profiles, that
would generate different capabilities documents. Stuff like:
http://…/ows?SERVICE=WMS&REQUEST=GetCapabilities&srsProfile=full
http://…/ows?SERVICE=WMS&REQUEST=GetCapabilities&srsProfile=limited
and then have a few more capabilities links in the UI.
(btw, smart == limited, layers always show up in their native
projection anyways afaik?)
How does this sound?
Ok, yeah, this is the point.
GeoServer is hugely capable, the default (and I assume rarely changed) configuration is to advertise everything, and this effectively renders the capabilities doc useless (or less handy at least) to subset of clients. (Let's say it is a separate discussion to determine which clients should and should not be asking GeoServer about its capabilities.)
Your suggestion is to allow clients to advertise something about their own capabilities ("I only care to parse limited capabilities docs" or "please send me a list of everything under the sun").
I also like Arne's suggestion about allowing the client to advertise a bit more ("I only care about your capabilities if you support these SRS").
The srsProfile parameter in a query is a handy shortcut, but requires the client and server to share some understanding about the meaning.
A more flexible solution would allow a client to say something like: tell me what you've got in this region, in these SRS, etc.
This gets beyond the initial motivation, but as long as we're talking about allowing a client to ask for a filtered set of capabilities, is it nuts to think about BBOX and SRS filters?
Tim
Cheers
Andrea
!DSPAM:4033,483e8629325215332866982!
