On 10/14/07, André Bargull <[EMAIL PROTECTED]> wrote: > Hi Henry, > > I've got at least one question regarding "LzHTTPLoader.js": > Why do we define "LzHTTPLoader.activeRequests" as an array, what about > changing it to an object, so that we can control all pending requests > with an id. That'd possibly improve performance, because that way we > don't need to loop over the whole activeRequests-array all the time. > To give you an idea what I actually mean, I'll just attach a working > copy of "LzHTTPLoader.js". >
Yes, that was an inefficient implementation, I did initially to get the DHTML data loading up and running. Thanks for updating it! > Additionally to this one, the version of "LzHTTPLoader.js" resolves two > bugs: > - In "LzHTTPLoader#__LZcheckXMLHTTPTimeouts(..)" we've got an assignment > to "this.req", but it must be "loader.req". > - added a check for finite value before setting up timeout, b/c > "setTimeout(..)" with a nonfinite duration is handled differently across > browsers (Firefox really waits forever, IE doesn't wait at all). Thanks I will review it. > > There is only left one major bug/issue: > What about calling doRequest in rapid succession, so that you'll > override a pending XMLHttpRequest on a LzHTTPLoader? How should we > handle this case? Abort the previous request or deny creating a new > request? What do we do in SWF? This is a very good question. We just recently re-modularized the data request mechanism for 4.0.5, and there is a writeup at http://wiki.openlaszlo.org/Dataprovider of the new DataProvider and DataRequest interfaces. They are pretty close to what is implemented now, but I need to make a pass over the wiki page to make it match what got implemented a little better. There is a new flag dataset.multirequest, which as I understand it says that, when false, any previous outstanding requests which have not yet returned should be aborted if possible, or ignored when they return. (There's an old comment from Adam in the swf code that says that aborting requests in Flash used to cause crashing, so the return values are just ignored now). If dataset.multirequest is true, then a new loader object is allocated for each request, and all of the responses are turned into ondata events when they arrive. There is also an old flag on dataset which has been around for a long time, called dataset.queuerequests, which is slightly different from dataset.multirequest. If true, it says not only to support multiple requests, but to try to serialize the responses so that ondata events from returning requests are sent in the same order that the requests were issued. This behavior is currently only implemented in the SWF runtime. [Side Note: To really ensure that the multiple requests to a datset were handled at the server in the same order they were issued, the dataset would have to wait until the the previous request returned and it's ondata event was sent, before sending the next queued request for that dataset. We have never tried to do that level of queuing/serializing. Developers should do that logic at the application level anyway, I think] > > And finally, for your interest: > Different browser behaviour after calling "XMLHttpRequest#abort()" > - Firefox: sets "XMLHttpRequest#readyState" to 4, but reading > "XMLHttpRequest#status" results in an error (as already discussed) > - IE6(7?): sets "XMLHttpRequest#readyState" to 4, > "XMLHttpRequest#status" will be set to 0 > - Opera: nothing. Yes, Opera does not change "XMLHttpRequest#readyState"! > > Best regards, > André > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
