Does anyone know where I can get some information about "streaming HTML"? I've seen a Perl/HTML chat package that looks almost about as good as JAVA chat - but without JAVA (in German, http://www.mainchat.de). They sell their package for about $2000 so I need to work something out myself... I got a HTML chat running, but really would be highly interested in learning about how to get "streaming HTML" to work... any suggestions?

The first thing would be to check the web standards site http://www.w3.org/, and/or do a search for streaming html and just start following links until you start find information about it.

Thanks for the tip... however, after an hour long search and clicking, I found no useful information ...

If it's a new technology, that only one group is using, there might not be any data yet. Given time, there will be. Usually, you can tell how well accepted a technology is by how much information is out there on it. If there isn't much, it's either new, or not too widely used.

Keep looking. Usually I find success right when I'm ready to give up.

When you "stream" html, it is just like when you "stream" anything else. You can use frames and JavaScript to run a metered update from the server. You generally use a hidden frame set to reload on a regular interval. Each time it reloads, it checks for new messages, then a JavaScript that loads with the page takes the new messages and adds them to the buffer. That is all the JAVA chat programs do, except that the data is loaded in plain text rather than bringing the loading code with it, which is a little faster.


James Hall

<a href="mailto:james@de-inc.com">james@de-inc.com</a>

ICQ: 72409850

Just a technical question -- if a browser does a reload, isn't it client-pull not streaming?

Streaming would be data is updated as it's sent without needing to reload -- like Real media files.

In technology, the only true push is radio and TV, where there is no two-way communication. With computers, pull and push is more a frame of mind. The data streamed to the browser is still based off of a generated connection. Push vs. pull is more about a ratio of requests sent vs packages recieved. You cannot really push anything over the web, unless the line of communication is laid first. Otherwise it would be like where web sites were radio antenaes with computers just recieving and parsing the information they broad cast. Hopefully, this made some sense. True, what I mentioned was more of a pull, but it is the best way I know to impliment a chat using HTML rather than Java, ActiveX, or something along those lines.

James Hall

<a href="mailto:james@de-inc.com">james@de-inc.com</a>

ICQ: 72409850

The reason I asked, is that even though it's a subtlty, it makes a _big_ difference in a programmers (or developers) mind. :)

When I hear streaming, I think of what real media has done. The program has a buffer, the two-step between the client-server to keep the buffer full is not apparant to the "browser" or the user. It's a proprietary (or non-browser) technology maintaining the "stream". There is no "refresh" or browser/client request to send more data.

If you are doing a "reload" or "refresh" then really you don't need to think about streaming. Client pull is really all you are doing.

This is much simpler, because all the server has to do is make sure the data being pulled is refreshed, and the client determines how often it wants to see it. It's also much more efficient in many ways.

There are ways of making this look "smooth" and psuedo-streaming..... such as a java "ping" of the server to see if the out-put buffer had changed, and if so, update the chat window. But this is again psuedo streaming, and for chat would be more efficient than trying to maintain a stream. Streaming is for broadcast... perhaps a large chat.

Anyway, I'm not a "purist" on most things, but this really looked like it was mixing apples and oranges, or trying to put a new face on an old friend, and call it something else.

As a last thought -- wouldn't "streaming HTML" actually not be possible, since the HTML definition requires closing tags to display the page? And really what is streaming is content to a client-window inside the browser/html page? Sometimes walking around the "problem" helps clear it up <G>

The only problem with streaming HTML is Timeouts and the fact that most browsers need you to be working in a closed tag environment. Netscape for example requires a closed table before it draws the table, or sometimes it waits for the close of the HTML. Explorer streams HTML is this fashion pretty well, but I have had some difficulties with Netscape. The other thing you need to think about when streaming HTML is how many processes you have running on the server. I am not great at background perl scripts, but what you would want is a single running program that would feed out messages as they came in. For example, an on-demand script would feed the HTML header, and then refer to the background feed directly.

The net result is streaming HTML, but the complications of going from an on-demand script to a centralized feed programming, without running the feed through the on-demand process is beyond me. With this method, it would be essential that you get it so that you are only running a single process. The initial call process would have to terminate to keep the server from over populating.

I have always preferred the pseudo-stream method, where the buffer actively collects the new data. You can also stream JavaScript when it is encapsulated in HTML. Each encapsulation of JavaScript is interpretted on demand.

James Hall

<a href="mailto:james@de-inc.com">james@de-inc.com</a>

ICQ: 72409850