[OpenLayers-Dev] Tile.checkImgURL, path processing

Erik Uzureau euzuro at gmail.com
Thu Jan 18 16:50:34 EST 2007


I would vote for #2, but that's probably only because I spent an
absurd amount of hours fixing the damn function so that it works
(which, by the way, it now does, afai can tell)

can i vote for option #5, which would be
option #1 + checking my fix for that code into trunk so that if ever
at some point in the future we want/need to use an url comparison
function we have one? :-/

?
e

On 1/18/07, Schuyler Erle <sderle at metacarta.com> wrote:
> 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
> >
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



More information about the Dev mailing list