[OpenLayers-Dev] Tile.checkImgURL, path processing

[Paul Spencer]

Chris,

I agree that it is bad to hide problems.  If the code should work and  
doesn't for some reason, hiding the result may be covering up other,  
more serious, issues elsewhere - which seems to be what was happening  
with Grid.js I guess.

My vote is for option 1.  You could leave a comment in the code for  
posterity, though :)  Then if the problem resurfaces and someone else  
is trying to track it down, it will be a bit easier.

Cheers

Paul

On 18-Jan-07, at 11:36 AM, Christopher Schmidt wrote:

> Currently, OpenLayers has a function in the Tile, called checkImgURL,
> which checks that a Tile has the same source after it was loaded as we
> expect it to, and otherwise hides the tile.
>
> This function was partly debugging and partly important: for a time,
> tiles were loading where they shouldn't have been, and it was causing
> problems.
>
> However, I think that this behavior is now fixed: a tile never  
> loads and
> has a different source than the one we asked it for. (As proof of  
> this,
> you can try turning this function off: I do it in all of the places  
> that
> I set up OpenLayers, pretty much.) The code to do this is:
>
> OpenLayers.Tile.Image.prototype = OpenLayers.Class.inherit(
>   OpenLayers.Tile.Image, { checkImgURL: function() {} });
>
> A side effect of this check, because of the way that browsers process
> URLs, is that it breaks relative URLs in Firefox. Fixing this so  
> that it
> works well is a difficult problem -- essentially, it takes the same
> difficulty as writing a full URL path parser. (Python's urlparse  
> module
> is an example of code which does this, and it's non-trivial.)
>
> At this point, I think that we've solved the problem this function was
> trying to prevent in other ways, via improvements to the Grid.js code,
> etc.
>
> I'm in favor of removing this check. The benefits:
>  * No URL path parsing, so relative URLs will work again in FF, for
>    example.
>  * No need to implement a complex functionality for checking URLs
>    which is seldom used.
>
> Cons:
>  * Possibly no longer hiding possible errors where somehow the  
> tile.src
>    changes during the load, but the tile doesn't load the correct URL.
>
> There is another option of making this check optional, turned off by
> default, and settable as an option on a layer. That way, we could keep
> the current behavior for people who want it, but since it has caused
> more harm than good, default it to off. This would be useful if we  
> find
> that there *is* some utility offered by this code which is not obvious
> in the use cases I have: if this is the case, then a user could simply
> turn on the function on a layer specific basis.
>
> This needs to be resolved before the 2.3 release, or at least  
> discussed
> and the conclusion being "Leave it as is."
>
> Personally, I'm in favor of (in descending order):
>  1. Removing the code. It hides errors, it doesn't fix them, and I  
> dont'
>     think it's neccesary, even though I used to think it was (and it
>     probably was until 2.3 because of other bugs in Grid.js)
>  2. Adding an OpenLayers.Layer option to use it or not use it,  
> defualting
>     to off.
>  3. Adding an OpenLayers.Layer option to use it or not use it,  
> defaulting
>     to on (maintains current behavior)
>  4. Leaving as is, where some browsers can't support relative  
> paths, etc., and
>     punting to the next release on solving it.
>
> Can I get a  vote for 1, 2, 3 or 4? After 24 hours, I'll take this to
> the PSC, and then we can move forward with the next 2.3 RC2, which has
> been blocking on this issue.
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+