Topic awaiting preservation: "Streaming" JS? $Pages that link to <a href="https://ozoneasylum.com/backlink?for=8782" title="Pages that link to Topic awaiting preservation: &quot;Streaming&quot; JS?" rel="nofollow" >Topic awaiting preservation: "Streaming" JS?\$

Author	Thread
Scott Bipolar (III) Inmate From: schillmania.com Insane since: Jul 2002	posted 07-26-2003 23:08 Just wondering if anyone's had any luck in trying to create a "persistent" client-side -> server connection in order to "stream" Javascript or other data to the client and parse it as it comes down (eg. for a simple chat application etc.) I've tried playing with IE's XMLHTTP object, no luck (can't parse before the document has fully loaded - ie. the connection has closed - despite documentation saying otherwise in some places).. tried dynamically creating a <script> element and loading from a connection that would spit out JS without closing the connection, but the script would not execute or be accessible until the connection had closed there (if no "content-length" was provided, and the connection was closed - or if content-length was specified and that amount of data had been passed down). I'm trying to just open a connection and send data back and forth, ideally without using iFrames or reloading.. something truly "persistent". Anyone done this before?
bitdamaged Maniac (V) Mad Scientist From: 100101010011 <-- right about here Insane since: Mar 2000	posted 07-27-2003 00:11 I still haven't found a good way to do this. I've toyed with the idea of a small flash movie that can pass data back and forth. .:[ Never resist a perfect moment ]:.
poi Paranoid (IV) Inmate From: France Insane since: Jun 2002	posted 07-27-2003 03:48 Scott: I'm not sure to really understand your question and requirements, but your chat application example reminded me a small sort of IRC application ( with public and private chatrooms, and user status ) I began when I learnt PHP. Basically, the thing used remote scripting. To send a message, I used a FORM and posted the datas in an IFRAME with a PHP script updating the database. To display the new messages, I used an IFRAME ( refreshed every second ) with a PHP script generating a bunch of JavaScript function calls in the parent frame to add the messages written during the previous seconde in its DOM. Obviously you can use a single IFRAME, replace the IFRAMEs by some OBJECTs but it would make no real difference. In XML/XSL compliant browsers you could also return the new messages in XML format and transform them with an XSL all on client side. To retrieve the messages you could load the following XML file "getMessagesSentSinceThisTimestampInXml.php?timestamp="+(new Date()).valueOf() and voilà. If you prefer, you could point to the more convenient "messages.xml" filename at the cost of a little tweak in your .htaccess and some minor changes in the XML and XSL files. Hope that helps. Mathieu "POÏ" HENRI [This message has been edited by poi (edited 07-27-2003).]
Dracusis Maniac (V) Inmate From: Brisbane, Australia Insane since: Apr 2001	posted 07-27-2003 09:22 I think Scott was asking about something that didn't require a polling method to retrive information. I don't know if this can be done with browser technologies however, there was a strange chat app tossed around here about 2 yeas back, used some XML and IE only stuff; little heads lips moved when users typed and all but I don't know where it came form. However, I do know it can be down in flash with various technologies. I've read a little bit about setting up socket servers with PHP, but not enough to attempt something like this myself but I'll be looking into this later on in the year for my information architecture class. However, most shared web hosts probably won't let you install socket servers even though their more efficient than using a polling solution. [This message has been edited by Dracusis (edited 07-27-2003).]
poi Paranoid (IV) Inmate From: France Insane since: Jun 2002	posted 07-27-2003 14:29 Dracusis: you're right. 3 times right. While focusing on the chat apprlication example I lost track of the "persistent" aspect. To counter the lack of control on the socket layer of the server, I wonder if an infinte loop with output buffer flushes whenever needed wouldn't do the trick. Here comes the sources code: <html> <body> intial content<br/> <iframe src="persistent.php" style="display:none"></iframe> </body> <script> messagesCount = 0 function addMessage( newMessage ) { document.body.innerHTML += "message #"+ messagesCount +" <span style='color:green'>"+ newMessage +"</span><br/>"; messagesCount++ } </script> </html> and the code of persistent.php code: <? set_time_limit( 0 ); // no timeout $newMessageProbability = 75; while( 1 ) { $sendNewMessage = mt_rand( 0, 100 ) < $newMessageProbability; // send a new message if( $sendNewMessage ) { echo "<script language='javascript'>\n"; echo "top.addMessage( 'BLAH BLAH sent ". date( "D M j G:i:s T" ) ." from ". $PHP_SELF ."' )\n"; echo "</script>\n"; ob_flush(); } // sleep a little sleep( 1 ); } ?> Those scripts works with PHP 4.2.0 , APACHE 1.3, IE6.0 and MZ1.4. I've tried to open 6 browsers during several minutes and the system didn't crawl. But the method requires some real torture test to prove its validty in real applications. Hope I didn't missed again. Mathieu "POÏ" HENRI [This message has been edited by poi (edited 07-29-2003).]
Emperor Maniac (V) Mad Scientist with Finglongers From: Cell 53, East Wing Insane since: Jul 2001	posted 07-27-2003 15:05 I'm not sure if it is any help but dCat use a DHTML front end for chat: http://sourceforge.net/projects/dchat/ www.asgleonberg.de/dchat/ ___________________ Emps FAQs: Emperor
Dracusis Maniac (V) Inmate From: Brisbane, Australia Insane since: Apr 2001	posted 07-28-2003 08:03 Poi, that's a nice solution for working with your everyday LAMP host, I'll have to try that out some day. I've been doing a bit of research on this and I've found a bunch of info on PHP sockets: http://www.php.net/manual/en/ref.sockets.php http://www.devshed.com/Server_Side/PHP/SocketProgramming/page1.html http://www.phpbuilder.com/columns/armel20010427.php3 Here's some stuff about using flash 5's XML socket server stuff: http://www.michael-thomas.com/flash/Flash5Socket/ http://chattyfig.figleaf.com/flashcoders-wiki/index.php?XML%2FXMLSocket%20Servers This forum has a bunch of discussions about different ways to use server side technologies with flash http://www.flash-db.com/Board/index.php?board=9 including some rather knowledagble people who've played with persistent connetions using PHP socket servers. I don't know if you'll be able to find a truly persistent solution that's cross browser and doesn't require a plugin, but using a hidden flash embed as a go-between would certainly be a possible solution, since Mozilla 1.1 can script to objects/plugins, it's certainly worth looking into. Edit: Reformatting -- this forum has a habbit of eating linebreaks when auto parsing links. [This message has been edited by Dracusis (edited 07-28-2003).]
trib Paranoid (IV) Inmate From: Den Haag, Netherlands Insane since: Sep 2002	posted 07-28-2003 19:30 My son-in-law wrote a chatd which used straight html/dhtml at the client end and maintained a persistent connection by exploiting a little known document type which never "finished" .. that was opened in a frame, and used as a pipeline reciever ... I can ask him what it was when he's back from holiday. He also wrote a server-side scripting language to support the protocol we devised. Got the whole thing going, and even incorporated on-the-fly translation to-from English to 6 European languages ... At one point we were even thinking of going commercial with it ... But be warned - if you're going at it from scratch, and doing it the DHTML way ... good luck ... it's a long slog and needs a specialised server daemon. I doubt you could do it througH Apache the way we did it .. he Wrote his own server in Java. My suggestion - use PHP with polling unless you really want to get in deep. Bug-free software only exisits in two places A programmer's mind and a salesman's lips
Steve Maniac (V) Inmate From: Boston, MA, USA Insane since: Apr 2000	posted 07-28-2003 19:30 We used a Perl socket server at the GN. Piper wrote it and it's a beauty. Flash 5 liked it fine and MX does too. We had some problems initially, working out what the Perl socket server and the Flash front end each expected to get from one another, but it was solid and fast after that. I had plenty of little devils to nail down, but almost none of them were related to conversing with the socket server after we got over the first hurdles. I've heard to putting cusstom front ends on Jabber too, for a more IM-like transaction, but no first hand experience.
Scott Bipolar (III) Inmate From: schillmania.com Insane since: Jul 2002	posted 07-31-2003 18:39 I seem to have hit a nerve! Glad to see there are so many different thoughts on this.. us Web Development types are quite creative folks Anyways - Poi, you got me thinking.. using an iFrame was what my tests had been "missing" - I had been trying the same method as you for receiving messages from the server, however I was using a <script> element and was trying to load and execute code directly from there while the JS was still loading. This does not work, as the browser will not execute the script until it has finished downloading (ie. the connection has closed). However, using an iFrame you can "send" blocks of Javascript down the wire (as you have found), and the browser will execute the script but will keep the connection through the iFrame open as the document has not finished yet. I have been reading up on the HTTP request/response protocol and have been tinkering with that. I have been able to create a simple "chat" using this method, although it does not work currently in Mozilla.. the iFrame does not load properly it seems - I suspect I am missing some HTTP header info. My experiment uses a simple Socks app that takes two types of "clients" - either a "send" connection, ie. the browser loading from the iFrame, or a "receive" type where the browser has posted a GET request to the same URL (eg. ?data=something).. in the latter case, the server interprets the request and broadcasts it across all connected clients as a <script> block with a function call (like Poi's method below).. this works nicely, and I was able to have multiple users connect and send messages without issue. The browser kept the connection open for as long as I had the window open also, I never experienced any timeout issues. I think once I can figure out what HTTP headers I'm missing, this will work 100% in Mozilla and I can look into fixing up the server daemon, and using XML or something similar as the messaging protocol. Trib, I would be interested in hearing more about what your son-in-law used (It sounds like an iFrame trick, same sort of thing perhaps?) Thanks for all your input! If I get something solid I'll post a URL also in the near future. [This message has been edited by Scott (edited 07-31-2003).]
Scott Bipolar (III) Inmate From: schillmania.com Insane since: Jul 2002	posted 08-24-2003 08:56 Just a note, this is on a puny development box at my place.. so go easy on it It might be broken by the time you've read this even, or I might be working on it.. so if either happens to be the case, my apologies in advance! http://schill.dyndns.org/schill/rpc-js RPC-JS chat experiment ---------------------- v1.0.20030823
amikael Bipolar (III) Inmate From: övik Insane since: Dec 2002	posted 08-25-2003 16:11 http://www.naltabyte.com/body/main/auction.htm This app already does what you want done, and it's javascript-centric only. The trick is server-generated js-files serving up data-variables on the fly containing the latest input. (^-^)b
amikael Bipolar (III) Inmate From: övik Insane since: Dec 2002	posted 08-25-2003 20:46 The auction updates all the latest bids in real-time, colors the highest bid red, and if you write a message instead of a bid, and click 'contact' for the person you want to contact, the message is sent to that individual only. This only works if the person is available at the auction when you send the message though. (^-^)b
Scott Bipolar (III) Inmate From: schillmania.com Insane since: Jul 2002	posted 08-29-2003 03:46 Looks neat! They appear to use Javascript that's generated on-the-fly by ASP on the backend (as you mentioned), with some static content served also for the library functions etc. There's also a daemon of some sort, which I assume is the dynamic bit.. There appears to be some javascript calls to the server that pass arguments (requests, "sending" data presumably), although there's also a hidden form element in there with a "file" type - it's possible data is uploaded silently that way. The method I'm playing with is more "real-time" as there's no polling required, so data is sent as it's received in real-time. These guys have a neat implementation, but their site (err, this app rather) doesn't work in Mozilla. Arguably I learned a lot more experimenting with the idea myself, than from what I read on their web site.. but to their credit, they're presumably selling this application - they don't have to explain everything! [This message has been edited by Scott (edited 08-29-2003).]

Topic awaiting preservation: "Streaming" JS?\$

Author

Thread

Scott
Bipolar (III) Inmate

From: schillmania.com
Insane since: Jul 2002

posted 07-26-2003 23:08

Just wondering if anyone's had any luck in trying to create a "persistent" client-side -> server connection in order to "stream" Javascript or other data to the client and parse it as it comes down (eg. for a simple chat application etc.)

I've tried playing with IE's XMLHTTP object, no luck (can't parse before the document has fully loaded - ie. the connection has closed - despite documentation saying otherwise in some places).. tried dynamically creating a <script> element and loading from a connection that would spit out JS without closing the connection, but the script would not execute or be accessible until the connection had closed there (if no "content-length" was provided, and the connection was closed - or if content-length was specified and that amount of data had been passed down).

I'm trying to just open a connection and send data back and forth, ideally without using iFrames or reloading.. something truly "persistent". Anyone done this before?

bitdamaged
Maniac (V) Mad Scientist

From: 100101010011 <-- right about here
Insane since: Mar 2000

posted 07-27-2003 00:11

I still haven't found a good way to do this. I've toyed with the idea of a small flash movie that can pass data back and forth.

.:[ Never resist a perfect moment ]:.

poi
Paranoid (IV) Inmate

From: France
Insane since: Jun 2002

posted 07-27-2003 03:48

Scott: I'm not sure to really understand your question and requirements, but your chat application example reminded me a small sort of IRC application ( with public and private chatrooms, and user status ) I began when I learnt PHP.

Basically, the thing used remote scripting. To send a message, I used a FORM and posted the datas in an IFRAME with a PHP script updating the database. To display the new messages, I used an IFRAME ( refreshed every second ) with a PHP script generating a bunch of JavaScript function calls in the parent frame to add the messages written during the previous seconde in its DOM.

Obviously you can use a single IFRAME, replace the IFRAMEs by some OBJECTs but it would make no real difference.
In XML/XSL compliant browsers you could also return the new messages in XML format and transform them with an XSL all on client side. To retrieve the messages you could load the following XML file "getMessagesSentSinceThisTimestampInXml.php?timestamp="+(new Date()).valueOf() and voilà. If you prefer, you could point to the more convenient "messages.xml" filename at the cost of a little tweak in your .htaccess and some minor changes in the XML and XSL files.

Hope that helps.

Mathieu "POÏ" HENRI

[This message has been edited by poi (edited 07-27-2003).]

Dracusis
Maniac (V) Inmate

From: Brisbane, Australia
Insane since: Apr 2001

posted 07-27-2003 09:22

I think Scott was asking about something that didn't require a polling method to retrive information.

I don't know if this can be done with browser technologies however, there was a strange chat app tossed around here about 2 yeas back, used some XML and IE only stuff; little heads lips moved when users typed and all but I don't know where it came form.

However, I do know it can be down in flash with various technologies. I've read a little bit about setting up socket servers with PHP, but not enough to attempt something like this myself but I'll be looking into this later on in the year for my information architecture class. However, most shared web hosts probably won't let you install socket servers even though their more efficient than using a polling solution.

[This message has been edited by Dracusis (edited 07-27-2003).]

poi
Paranoid (IV) Inmate

From: France
Insane since: Jun 2002

posted 07-27-2003 14:29

Dracusis: you're right. 3 times right. While focusing on the chat apprlication example I lost track of the "persistent" aspect.

To counter the lack of control on the socket layer of the server, I wonder if an infinte loop with output buffer flushes whenever needed wouldn't do the trick. Here comes the sources

code:

<html>

<body>

intial content<br/>

<iframe src="persistent.php" style="display:none"></iframe>

</body>

<script>

messagesCount = 0

function addMessage( newMessage )

{

    document.body.innerHTML += "message #"+ messagesCount +" <span style='color:green'>"+ newMessage +"</span><br/>";

    messagesCount++

}

</script>

</html>

and the code of persistent.php

code:

<?

set_time_limit( 0 );  // no timeout

$newMessageProbability = 75;

while( 1 )

{

    $sendNewMessage = mt_rand( 0, 100 ) < $newMessageProbability;

    // send a new message

    if( $sendNewMessage )

    {

        echo "<script language='javascript'>\n";

        echo "top.addMessage( 'BLAH BLAH sent ". date( "D M j G:i:s T" ) ." from ". $PHP_SELF ."' )\n";

        echo "</script>\n";

        ob_flush();

    }

    // sleep a little

    sleep( 1 );

}

?>

Those scripts works with PHP 4.2.0 , APACHE 1.3, IE6.0 and MZ1.4. I've tried to open 6 browsers during several minutes and the system didn't crawl. But the method requires some real torture test to prove its validty in real applications.

Hope I didn't missed again.

Mathieu "POÏ" HENRI

[This message has been edited by poi (edited 07-29-2003).]

Emperor
Maniac (V) Mad Scientist with Finglongers

From: Cell 53, East Wing
Insane since: Jul 2001

posted 07-27-2003 15:05

I'm not sure if it is any help but dCat use a DHTML front end for chat:
http://sourceforge.net/projects/dchat/
www.asgleonberg.de/dchat/

___________________
Emps

FAQs: Emperor

Dracusis
Maniac (V) Inmate

From: Brisbane, Australia
Insane since: Apr 2001

posted 07-28-2003 08:03

Poi, that's a nice solution for working with your everyday LAMP host, I'll have to try that out some day.

I've been doing a bit of research on this and I've found a bunch of info on PHP sockets:
http://www.php.net/manual/en/ref.sockets.php
http://www.devshed.com/Server_Side/PHP/SocketProgramming/page1.html
http://www.phpbuilder.com/columns/armel20010427.php3

Here's some stuff about using flash 5's XML socket server stuff:
http://www.michael-thomas.com/flash/Flash5Socket/
http://chattyfig.figleaf.com/flashcoders-wiki/index.php?XML%2FXMLSocket%20Servers

This forum has a bunch of discussions about different ways to use server side technologies with flash http://www.flash-db.com/Board/index.php?board=9 including some rather knowledagble people who've played with persistent connetions using PHP socket servers.

I don't know if you'll be able to find a truly persistent solution that's cross browser and doesn't require a plugin, but using a hidden flash embed as a go-between would certainly be a possible solution, since Mozilla 1.1 can script to objects/plugins, it's certainly worth looking into.

Edit: Reformatting -- this forum has a habbit of eating linebreaks when auto parsing links.

[This message has been edited by Dracusis (edited 07-28-2003).]

trib
Paranoid (IV) Inmate

From: Den Haag, Netherlands
Insane since: Sep 2002

posted 07-28-2003 19:30

My son-in-law wrote a chatd which used straight html/dhtml at the client end and maintained a persistent connection by exploiting a little known document type which never "finished" .. that was opened in a frame, and used as a pipeline reciever ... I can ask him what it was when he's back from holiday.

He also wrote a server-side scripting language to support the protocol we devised. Got the whole thing going, and even incorporated on-the-fly translation to-from English to 6 European languages ... At one point we were even thinking of going commercial with it ...

But be warned - if you're going at it from scratch, and doing it the DHTML way ... good luck ... it's a long slog and needs a specialised server daemon. I doubt you could do it througH Apache the way we did it .. he Wrote his own server in Java.

My suggestion - use PHP with polling unless you really want to get in deep.

Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

Steve
Maniac (V) Inmate

From: Boston, MA, USA
Insane since: Apr 2000

posted 07-28-2003 19:30

We used a Perl socket server at the GN. Piper wrote it and it's a beauty. Flash 5 liked it fine and MX does too. We had some problems initially, working out what the Perl socket server and the Flash front end each expected to get from one another, but it was solid and fast after that. I had plenty of little devils to nail down, but almost none of them were related to conversing with the socket server after we got over the first hurdles.

I've heard to putting cusstom front ends on Jabber too, for a more IM-like transaction, but no first hand experience.

Scott
Bipolar (III) Inmate

From: schillmania.com
Insane since: Jul 2002

posted 07-31-2003 18:39

I seem to have hit a nerve! Glad to see there are so many different thoughts on this.. us Web Development types are quite creative folks

Anyways - Poi, you got me thinking.. using an iFrame was what my tests had been "missing" - I had been trying the same method as you for receiving messages from the server, however I was using a <script> element and was trying to load and execute code directly from there while the JS was still loading. This does not work, as the browser will not execute the script until it has finished downloading (ie. the connection has closed).

However, using an iFrame you can "send" blocks of Javascript down the wire (as you have found), and the browser will execute the script but will keep the connection through the iFrame open as the document has not finished yet. I have been reading up on the HTTP request/response protocol and have been tinkering with that. I have been able to create a simple "chat" using this method, although it does not work currently in Mozilla.. the iFrame does not load properly it seems - I suspect I am missing some HTTP header info.

My experiment uses a simple Socks app that takes two types of "clients" - either a "send" connection, ie. the browser loading from the iFrame, or a "receive" type where the browser has posted a GET request to the same URL (eg. ?data=something).. in the latter case, the server interprets the request and broadcasts it across all connected clients as a <script> block with a function call (like Poi's method below).. this works nicely, and I was able to have multiple users connect and send messages without issue. The browser kept the connection open for as long as I had the window open also, I never experienced any timeout issues.

I think once I can figure out what HTTP headers I'm missing, this will work 100% in Mozilla and I can look into fixing up the server daemon, and using XML or something similar as the messaging protocol. Trib, I would be interested in hearing more about what your son-in-law used (It sounds like an iFrame trick, same sort of thing perhaps?)

Thanks for all your input!

If I get something solid I'll post a URL also in the near future.

[This message has been edited by Scott (edited 07-31-2003).]

Scott
Bipolar (III) Inmate

From: schillmania.com
Insane since: Jul 2002

posted 08-24-2003 08:56

Just a note, this is on a puny development box at my place.. so go easy on it It might be broken by the time you've read this even, or I might be working on it.. so if either happens to be the case, my apologies in advance!
http://schill.dyndns.org/schill/rpc-js

RPC-JS chat experiment
----------------------
v1.0.20030823

amikael
Bipolar (III) Inmate

From: övik
Insane since: Dec 2002

posted 08-25-2003 16:11

http://www.naltabyte.com/body/main/auction.htm

This app already does what you want done, and it's javascript-centric only.
The trick is server-generated js-files serving up data-variables on the fly containing the latest input.

(^-^)b

amikael
Bipolar (III) Inmate

From: övik
Insane since: Dec 2002

posted 08-25-2003 20:46

The auction updates all the latest bids in real-time, colors the highest bid red, and if you write a message instead of a bid, and click 'contact' for the person you want to contact, the message is sent to that individual only.
This only works if the person is available at the auction when you send the message though.

(^-^)b

Scott
Bipolar (III) Inmate

From: schillmania.com
Insane since: Jul 2002

posted 08-29-2003 03:46

Looks neat! They appear to use Javascript that's generated on-the-fly by ASP on the backend (as you mentioned), with some static content served also for the library functions etc.

There's also a daemon of some sort, which I assume is the dynamic bit.. There appears to be some javascript calls to the server that pass arguments (requests, "sending" data presumably), although there's also a hidden form element in there with a "file" type - it's possible data is uploaded silently that way.

The method I'm playing with is more "real-time" as there's no polling required, so data is sent as it's received in real-time. These guys have a neat implementation, but their site (err, this app rather) doesn't work in Mozilla. Arguably I learned a lot more experimenting with the idea myself, than from what I read on their web site.. but to their credit, they're presumably selling this application - they don't have to explain everything!

[This message has been edited by Scott (edited 08-29-2003).]