[OpenLayers-Dev] Tile.checkImgURL, path processing
Tim Schaub
noreply at geocartic.com
Fri Jan 19 01:09:43 EST 2007
+1 for option #5 from me too.
I agree that Tile.checkImgURL is a bad idea (hence my voodoo comment on
#467).
I also agree that the Util.isEquivalentUrl code should be properly patched
and left in. I wrote it originally so that it could be used in tests also
(and I seemed to have some other ideas for it as well) - and I know Erik put
a lot of sweat into making it work.
Tim
> -----Original Message-----
> From: dev-bounces at openlayers.org
> [mailto:dev-bounces at openlayers.org] On Behalf Of Erik Uzureau
> Sent: Thursday, January 18, 2007 2:51 PM
> To: Schuyler Erle
> Cc: dev at openlayers.org
> Subject: Re: [OpenLayers-Dev] Tile.checkImgURL, path processing
>
> 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
> >
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
More information about the Dev
mailing list