Re: [udig-devel] WMS-C hackery - review please?

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Hi Emily:

I noticed I was unable to commit after sending that email; my commit
has gone through now.

> Question - can we display them but not allow people to add them to the map?
>  Sort of like services that we can't connect to.  This would allow people to
> know they are there but there is some issue with them.
> If not, then I guess you can hide them; it might confuse people though.  I
> know I would get a little confused if I looked at the getCapabilities
> document and saw it and then didn't see it in udig.

I think we can do something; maybe display them grayed out if they do
not have a "info"? The thing is we *try* and display data with no info
 usually (by assuming generic 2d and in many cases we can get away
with it).

I think the best thing is to support the google projection.

> For the readCapabilities document I don't see any reason why we can't just
> use service.  I think when we first wrote it I assumed that you had to strip
> off all the arguments, but it seems that is an incorrect assumption.

Okay that makes sense; I did patch the code (and isolate the
processing of the URL to a single function). When you get a chance to
update you may wish to remove this ...

In the normal WMS code I do process the function; adding in
Request=GetCapabilities; Service=WMS and version if needed. I think we
need to do the same here - including adding tiled=true.  However we
also need to maintain the query parameters that were there already -
map server indicates what map file it is using that way. And geoserver
is looking to do similar things with profiles and maps in the future.

> In terms of the buildBaseTileRequestFunction - I think if we just return
> service.toString() we'll get duplicate 'request=' parameters and confuse the
> wmsc?

Correct - but we should be using the WMS GetMap request it provided
for us (which may not have anything to do with the capabilities end
point).

>> - decided to hold onto the couldNoTConnect exception and rethrow
>> rather than parse each time
>
> Where are you doing this?  I suspect it is fine; however I'm wondering what
> happens if you have a poor internet connection and you have intermittent
> connections.  I seem to recall trying to connect with one tile and getting
> and error and trying again with a second tile and getting that tile.  Maybe
> I don't understand what you are saying here.

Now that the code is committed I think you can review this part. My
problem ended up being that it would connect once; fail; then connect
again during the dispose method (in order to try and get members to
dispose!) and in general was very slow to fail.

>> - Service.dispose() was tripping up and calling members() in order to
>> dispose each member; if we were unable to connect - this call made the
>> WMSC code try and connect again!
>
> Ok this doesn't sound good; I assume you fixed it?

I did; the fix is in the IService super class.

Jody