[OpenLayers-Dev] Tile.checkImgURL, path processing

[Schuyler Erle]

I agree completely. I vote for option #1 along with a comment in the
code.

SDE

On Thu, 2007-01-18 at 12:47 -0500, Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
> 
> 
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>