[Laszlo-dev] Questions regarding "LzHTTPLoader.js"

Henry Minsky henry.minsky at gmail.com
Mon Oct 15 09:29:36 PDT 2007


On 10/14/07, André Bargull <a.bargull at intensis.de> 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
hminsky at laszlosystems.com



More information about the Laszlo-dev mailing list