XMLHTTPRequest streaming data

[Jim Ley]

Of course it wouldn't be streaming. Lacking a real and worthwhile
cross-browser way to implement streaming given the requirements of the
project, we're left with emulation.

but, the example method I've already given in the thread, is a much
better emulation, the problem as posed is that OP does not want to
wait for the entire file to download before anything happens -
completely reasonable. The option I suggested was to write a document
out

<script type="text/javascript">
parent.functionName("donkey");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("chicken");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("Moomin");
/* ... */
</script>

This method has the functions called as the document is loading, the
script executes as the file is loading, not just once onload.

Since you've neither asked for an explanation nor given one yourself,
there's little more to say than that.

I'd already given the example in the thread, maybe you could've
responded to that one if you think it was in some way bad?

Jim.

 

[Christopher J. Hahn]

but, the example method I've already given in the thread, is a much
better emulation, the problem as posed is that OP does not want to
wait for the entire file to download before anything happens -
completely reasonable. The option I suggested was to write a document
out

<script type="text/javascript">
parent.functionName("donkey");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("chicken");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("Moomin");
/* ... */
</script>

This method has the functions called as the document is loading, the
script executes as the file is loading, not just once onload.


I'd already given the example in the thread, maybe you could've
responded to that one if you think it was in some way bad?

Not at all, in and of itself. I thought I was pretty clear that onload
was being used as a component of the solution that the OP and I were
batting around. As a solution itself, your suggestion seems perfectly
reasonable to me. If the function call takes a single argument (the
JSON structure), then parsing the file from other client apps gets only
very slightly more complicated.

So no, I don't think it's in any way bad.

Whether or why the OP couldn't or wouldn't use it isn't entirely clear
to me, but I'm sure he has his reasons. If he couldn't, then onload
seems like a perfectly valid way to deal with multiple partial
responses consisting of JSON within an otherwise barren HTML container.
In the context of a complete response, I agree with you that it'd be
pointless and wouldn't even give the appearance of streaming, but
that's not the context we were discussing.

Please tell me if I've completely misunderstood.

 

[googlegroups]

<script type="text/javascript">
parent.functionName("donkey");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("chicken");
/* ... */
</script>

<script type="text/javascript">
parent.functionName("Moomin");
/* ... */
</script>

This seems like a pretty cool idea. I am going to have to give it a try
for either this project or another one at some point. Thanks for the
information.

Because we wanted to keep server overhead down we implemented a
throttle on the server replies. The throttle returns a couple hundred
rows of data, and then sends a failure message in the XML reply (looks
a lot like soap). If the failure message says that the throttle was
reached, I will simply parse all the data received, then request more
data from the server in a new request. A pretty bad hack I know. The
throttle works for the perl implementation, the javascript
implementation, and other languages as well.

Thanks,
Scott