Glow-project Glow

Comments and changes to this ticket

• 

  Jake Archibald October 30th, 2009 @ 11:48 AM

  The problem with this is Glow can no longer track 2 calls to the same URL. We're going to drop Safari 2 support in Glow 2, because of that we'll be able to use onLoad even without {callback}.

  Would that be enough, or is there a use-case this doesn't solve?

  We'd still support {callback} as first priority and onLoad would get whatever parameters the callback was called with. Otherwise we'd just detect when the script was loaded & fire onLoad without params.

• You flagged this item as spam.
  

  richardhodgson November 3rd, 2009 @ 02:55 PM

  So to confirm, Glow currently needs to create a unique handler for each request to a url?

  The problem I'm attempting to describe above is that becuase Glow randomly generates a callback, caching of that resource is broken. To avoid this, the jsonp callback name needs to always be the same, even after a page refresh.

  We like the Glow onLoad abstraction and would like to keep it. Allowing the user to specify the name of the callback as 'foo' would instruct glow to create a handler named 'foo', always call the target url with '?callback=foo' appended and pass the params back to onLoad.

  If some clever way of consistently hashing the url could be used, this would avoid the user having to specify 'foo' in the first place.

• 

  Jake Archibald November 3rd, 2009 @ 03:03 PM

  Yeah, I get the caching thing.

  We can now detect when a script has loaded, so we don't need ?callback=foo to trigger onLoad (or, we won't in Glow 2). Would this be enough? The difference is the onLoad callback wouldn't receive any parameters.

  glow.net.loadScript('whatever.js', {
    onLoad: function() {
      alert( whatever.msg );
      // we assume whatever.js creates whatever.msg
    }
  });
  

• You flagged this item as spam.
  

  richardhodgson November 3rd, 2009 @ 03:15 PM

  Sorry, was just confirming I'd explained it properly.

  At the moment, we make use of values passed in to onLoad. Any suggestions on how the data could be accessed without being passed in as arguments?

• 

  Jake Archibald November 3rd, 2009 @ 03:35 PM

  It could create globals (like my example above).

  Will consider adding the callback name thing. Just worried that it'll create difficult to track bugs when Glow can't tell the difference between 2 requests to the same url. Btw, the HTTP spec says that urls that have a querystring shouldn't cache, are there any browsers that obey this?

• You flagged this item as spam.
  

  richardhodgson November 3rd, 2009 @ 03:54 PM

  Creating a global occured to me, however that defeats the point of the using the Glow onLoad abstraction. We could just build a global callback and manually specify it in the url (without {callback}).

  I don't know enough about how Glow creates and tracks the requests it makes so I can't help you there.

  As for the HTTP spec:

  http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9
  "caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time"

  ...which I interpret to mean; if expiry headers have been set, honour them irrespective of the querystring. I have no idea which browsers adhere to this.

• 

  Jake Archibald November 3rd, 2009 @ 04:12 PM

  Basically, a request goes off to a script file which then calls a callback. If 2 requests have the same callback, Glow can't tell the 2 apart. We'd have to decide to fire each onLoad twice (doesn't really make sense), or fire each onLoad once but assume that the first callback was intended for the onLoad created by the first call to loadScript (which will be wrong if the files don't load in that order).

  glow.net.loadScript('posts.js?callback={callback}', {
      callbackName: 'myCallback',
      onLoad: function(posts) {
          // this 'posts' data may actually be 'users'
          alert(posts);
      }
  });
  
  // later...
  
  glow.net.loadScript('users.js?callback={callback}', {
      callbackName: 'myCallback',
      onLoad: function(users) {
          // 'users' may actually be 'posts' because the callbacks are the same
          alert(users);
      }
  });
  

  We don't have this problem at the moment, callback names are always unique (which also breaks caching), so we can always match a callback to the correct onLoad.