Page Streaming & Service Streaming

[chibineku]

I came across a couple of techniques for improving intensive AJAX/database applications, such as a web-based chat room, called page streaming and service streaming. I've read a bit about them, but it's mostly over my head. I was wondering if anyone here has used these techniques and could give me a little lesson, or just the bare bones necessary code so I can mull over it myself? It seems pretty cool. If it isn't cool, why not?Ta.

[Ingolme]

I don't think there's really such thing as "streaming" in the HTTP protocol.Streaming data is used by real programming languages. In the browser it could be Flash or Java.Maybe there's some technique I haven't heard of called "page streaming" and if it does exist I sure would like to learn about it.

[boen_robot]

I don't know about JavaScript, but in PHP, streaming is done with the output control functions, and flush() in particular. The basic idea is to output content as soon as possible, while doing the complicated work after that. See this topic for details on that.

[chibineku]

Quite an in-depth discussion of flush() etc., thanks.See I understood the first example that I found, which was for page streaming. The basic idea (in a chat app, for example) was to use PHP to periodically check a database for new messages, new users, etc., and when one was found, to echo the JavaScript to fetch it (AJAX). This way the connection with the server is prolonged. The article I read threw up all sorts of questions you need to answer before deciding how long to keep a connection alive - number of users, amount of data, whether the browsers/server will allow alive connections of that length, how many JavaScript functions the client can support in succession, and so on. It seems like a pretty barmy idea to me - surely it's better to poll the server every second than to keep the connection alive? But it was suggested to me on a different forum as a better solution.As for service streaming, I didn't really understand what it was about at all. I think, but this is just my take on what I read, that it involves making an AJAX call which will be made once. The PHP (or other server side code) again periodically checks for new data and flush()es it. In the JavaScript, you check to see if the data is different and if so, output it. Something like that. So at least the client's page gets to load. I was taught that if you were going to do something very intensive, do it client-side, because the browser will have proportionally greater resources than a busy server. So, let JavaScript do the timing and make your calls to the server efficient, albeit frequent.

[Synook]

See I understood the first example that I found, which was for page streaming. The basic idea (in a chat app, for example) was to use PHP to periodically check a database for new messages, new users, etc., and when one was found, to echo the JavaScript to fetch it (AJAX). This way the connection with the server is prolonged. The article I read threw up all sorts of questions you need to answer before deciding how long to keep a connection alive - number of users, amount of data, whether the browsers/server will allow alive connections of that length, how many JavaScript functions the client can support in succession, and so on. It seems like a pretty barmy idea to me - surely it's better to poll the server every second than to keep the connection alive? But it was suggested to me on a different forum as a better solution.

The concept of keeping HTTP connections alive for extended periods of time in order to wait for data is known as Comet. Facebook chat, for example, uses the method.

[chibineku]

Thanks, Synook. It's pretty interesting stuff. From that article, it seems that long-polling is the easiest and most reliable method to implement. My base-line example is a chat app, because I have one that works but which relies on periodic AJAX calls and is very server intensive (in fact, in the t&c for my webhost, it's actually expressly forbidden). Is there a benefit on making the PHP script do the checking for new data instead of creating a new XHR object every second or two? The effect will be a smoother and more responsive application, but is it less load on the server?