Real-time server push?

Discussion in 'Javascript' started by Martin, May 18, 2009.

  1. Martin

    Martin Guest

    I have web-based user interface for an industrial automation system
    that has some pages that display some activity and data in real time.
    I have two distinctly different ways of doing this - both of which
    have undesireable aspects.

    1: I use AJAX - with the browser requesting a refresh once per second.
    Since displayable information can be generated at any moment, I have
    to buffer it on the server-side and then I have a time-stamp on each
    piece of data so the client can tell if it's already displayed a
    particular item. This all works ok but the display in the browser
    isn't truely "real-time" - several events will appear on the screen at
    the same instant even though they actually occurred at slightly
    different times.

    2: I have page set up that downloads a dll from the server that
    contains a client-side socket that, when the page is loaded, connects
    to a socket on the server. I then shove data in true real-time from
    the server to the client page where it is displayed. All of the
    client/page side activity is controlled by VBScript (and DHTML). The
    problem here is that this works only with VBScript- and thus works
    only in Internet Explorer.

    I like the second approach better so, finally my question:

    Does anyone know if there is program available anywhere (perhaps a
    Java applet) that provides the same functionality as the DLL I'm
    currently using but would have the ability to be manipulated by
    Javascript? This would allow true real-time display of the data and
    would work in all browsers. FWIW, Javascript is already being used on
    all of my interface's pages.

    Thanks for any recommendations.
    Martin, May 18, 2009
    #1
    1. Advertising

  2. Martin wrote:
    > I have web-based user interface for an industrial automation system
    > that has some pages that display some activity and data in real time.
    > I have two distinctly different ways of doing this - both of which
    > have undesireable aspects.
    >
    > 1: I use AJAX - with the browser requesting a refresh once per second.
    > Since displayable information can be generated at any moment, I have
    > to buffer it on the server-side and then I have a time-stamp on each
    > piece of data so the client can tell if it's already displayed a
    > particular item. This all works ok but the display in the browser
    > isn't truely "real-time" - several events will appear on the screen at
    > the same instant even though they actually occurred at slightly
    > different times.
    >
    > 2: I have page set up that downloads a dll from the server that
    > contains a client-side socket that, when the page is loaded, connects
    > to a socket on the server. I then shove data in true real-time from
    > the server to the client page where it is displayed. All of the
    > client/page side activity is controlled by VBScript (and DHTML). The
    > problem here is that this works only with VBScript- and thus works
    > only in Internet Explorer.
    >
    > I like the second approach better so, finally my question:
    >
    > Does anyone know if there is program available anywhere (perhaps a
    > Java applet) that provides the same functionality as the DLL I'm
    > currently using but would have the ability to be manipulated by
    > Javascript? This would allow true real-time display of the data and
    > would work in all browsers. FWIW, Javascript is already being used on
    > all of my interface's pages.


    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <title>Realtime update</title>
    <script type="text/javascript">
    var refresh_int = 1000; // milliseconds
    function realt() {
    frames['r'].location = 'realtime.php?'+(new Date()).getTime();
    setTimeout('realt()', refresh_int);
    }
    </script>
    </head>
    <body onLoad="realt()">
    <iframe name="r"></iframe>
    </body>
    </html>

    If MSIE's loading bar would be annoying, you could execute 'realt()'
    in AJAX:

    var x = null;
    if (window.XMLHttpRequest) {
    x = new XMLHttpRequest();
    }
    else if (window.ActiveXObject) {
    x = new ActiveXObject('Microsoft.XMLHTTP');
    }
    if (x != null) {
    x.open('GET', 'realtime.php?'+(new Date()).getTime(), false);
    x.send(null);
    if (x.readyState == 4 && x.status == 200)
    frames['r'].location = 'realtime.php?'+ (new Date()).getTime();
    }
    setTimeout('realt()', refresh_int);

    Hope this helps,

    --
    Bart
    Bart Van der Donck, May 18, 2009
    #2
    1. Advertising

  3. Martin

    Jorge Guest

    Jorge, May 18, 2009
    #3
  4. Martin

    David Mark Guest

    On May 18, 10:57 am, Bart Van der Donck <> wrote:
    > Martin wrote:
    > > I have web-based user interface for an industrial automation system
    > > that has some pages that display some activity and data in real time.
    > > I have two distinctly different ways of doing this - both of which
    > > have undesireable aspects.

    >
    > > 1: I use AJAX - with the browser requesting a refresh once per second.
    > > Since displayable information can be generated at any moment, I have
    > > to buffer it on the server-side and then I have a time-stamp on each
    > > piece of data so the client can tell if it's already displayed a
    > > particular item. This all works ok but the display in the browser
    > > isn't truely "real-time" - several events will appear on the screen at
    > > the same instant even though they actually occurred at slightly
    > > different times.

    >
    > > 2: I have page set up that downloads a dll from the server that
    > > contains a client-side socket that, when the page is loaded, connects
    > > to a socket on the server. I then shove data in true real-time from
    > > the server to the client page where it is displayed. All of the
    > > client/page side activity is controlled by VBScript (and DHTML). The
    > > problem here is that this works only with VBScript- and thus works
    > > only in Internet Explorer.

    >
    > > I like the second approach better so, finally my question:

    >
    > > Does anyone know if there is program available anywhere (perhaps a
    > > Java applet) that provides the same functionality as the DLL I'm
    > > currently using but would have the ability to be manipulated by
    > > Javascript? This would allow true real-time display of the data and
    > > would work in all browsers. FWIW, Javascript is already being used on
    > > all of my interface's pages.

    >
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    >  "http://www.w3.org/TR/html4/loose.dtd">
    > <html>
    >  <head>
    >   <title>Realtime update</title>
    >   <script type="text/javascript">
    >    var refresh_int = 1000; // milliseconds
    >    function realt()  {
    >     frames['r'].location = 'realtime.php?'+(new Date()).getTime();
    >     setTimeout('realt()', refresh_int);
    >    }
    >   </script>
    >  </head>
    >  <body onLoad="realt()">
    >    <iframe name="r"></iframe>
    >  </body>
    > </html>
    >
    > If MSIE's loading bar would be annoying, you could execute 'realt()'
    > in AJAX:
    >
    >  var x = null;
    >  if (window.XMLHttpRequest)  {
    >   x = new XMLHttpRequest();
    >  }
    >  else if (window.ActiveXObject)  {
    >   x = new ActiveXObject('Microsoft.XMLHTTP');
    >  }
    >  if (x != null)  {
    >   x.open('GET', 'realtime.php?'+(new Date()).getTime(), false);
    >   x.send(null);
    >   if (x.readyState == 4 && x.status == 200)
    >    frames['r'].location = 'realtime.php?'+ (new Date()).getTime();
    >  }
    >  setTimeout('realt()', refresh_int);


    Polling with IFrames or XHR is hardly real time. It's Comet or
    nothing these days (at least for JS developers.)
    David Mark, May 18, 2009
    #4
  5. Martin

    Jorge Guest

    On May 18, 5:38 pm, David Mark <> wrote:
    > (...)
    > Polling with IFrames or XHR is hardly real time. It's Comet or
    > nothing these days (at least for JS developers.)


    1.- @the client: establish a comms channel with the server by sending
    a request (an xmlHttpRequest), and return.

    If/when the server has data to send:

    2.- @the server: the server sends real time data through the
    connection opened in step 1.
    3.- @the client: data received: an onreadyestatechange event happens.
    4.- @the client: the onreadyestatechange handler: gosub 1 and
    processes the data received in step 3.

    If the server has nothing to send:

    2.- @the client: the connection established in step 1 will eventually
    time out and trigger an onreadystatechange event with status !== 200.
    3.- @the client: the onreadyestatechange handler: gosub 1 and return.

    --
    Jorge.
    Jorge, May 18, 2009
    #5
  6. Martin

    David Mark Guest

    On May 18, 1:32 pm, Jorge <> wrote:
    > On May 18, 5:38 pm, David Mark <> wrote:
    >
    > > (...)
    > > Polling with IFrames or XHR is hardly real time.  It's Comet or
    > > nothing these days (at least for JS developers.)

    >
    > 1.- @the client: establish a comms channel with the server by sending
    > a request (an xmlHttpRequest), and return.
    >
    > If/when the server has data to send:
    >
    > 2.- @the server: the server sends real time data through the
    > connection opened in step 1.
    > 3.- @the client: data received: an onreadyestatechange event happens.
    > 4.- @the client: the onreadyestatechange handler: gosub 1 and
    > processes the data received in step 3.
    >
    > If the server has nothing to send:
    >
    > 2.- @the client: the connection established in step 1 will eventually
    > time out and trigger an onreadystatechange event with status !== 200.
    > 3.- @the client: the onreadyestatechange handler: gosub 1 and return.


    That's the pseudo-code for one transport. It's not the ideal choice
    for most cases.
    David Mark, May 18, 2009
    #6
  7. Martin

    Jorge Guest

    On May 18, 8:48 pm, David Mark <> wrote:
    > (...)
    > It's not the ideal choice
    > for most cases.


    It might not be "ideal", but it works in ~ any browser and doesn't
    require VB, Java, Flash nor SilverLight.

    --
    Jorge.
    Jorge, May 18, 2009
    #7
  8. Martin

    David Mark Guest

    On May 18, 4:15 pm, Jorge <> wrote:
    > On May 18, 8:48 pm, David Mark <> wrote:
    >
    > > (...)
    > > It's not the ideal choice
    > > for most cases.

    >
    > It might not be "ideal", but it works in ~ any browser and doesn't
    > require VB, Java, Flash nor SilverLight.


    Nothing I have recommended requires any of those either. Your pseudo-
    code demonstrates the LCD of the remaining choices. And it will not
    work in any browser.
    David Mark, May 18, 2009
    #8
  9. Hi Martin,

    "Martin" <> wrote in message
    news:p...
    > I have web-based user interface for an industrial automation system
    > that has some pages that display some activity and data in real time.
    > I have two distinctly different ways of doing this - both of which
    > have undesireable aspects.
    >
    > 1: I use AJAX - with the browser requesting a refresh once per second.
    > Since displayable information can be generated at any moment, I have
    > to buffer it on the server-side and then I have a time-stamp on each
    > piece of data so the client can tell if it's already displayed a
    > particular item. This all works ok but the display in the browser
    > isn't truely "real-time" - several events will appear on the screen at
    > the same instant even though they actually occurred at slightly
    > different times.
    >
    > 2: I have page set up that downloads a dll from the server that
    > contains a client-side socket that, when the page is loaded, connects
    > to a socket on the server. I then shove data in true real-time from
    > the server to the client page where it is displayed. All of the
    > client/page side activity is controlled by VBScript (and DHTML). The
    > problem here is that this works only with VBScript- and thus works
    > only in Internet Explorer.
    >
    > I like the second approach better so, finally my question:
    >
    > Does anyone know if there is program available anywhere (perhaps a
    > Java applet) that provides the same functionality as the DLL I'm
    > currently using but would have the ability to be manipulated by
    > Javascript? This would allow true real-time display of the data and
    > would work in all browsers. FWIW, Javascript is already being used on
    > all of my interface's pages.
    >
    > Thanks for any recommendations.
    >
    >


    If you just want a connection-oriented TCP/IP Java Socket example with one
    server thread or process per client, then there are many Java examples on
    the web. One such example is: -
    http://manson.vistech.net/t3$examples/demo_client_web.html

    All Java source code is in:
    http://manson.vistech.net/t3$examples/
    Warning: That code's a bit old now and optimistic in that it doesn't loop
    around until a "complete" message has been read.

    But again, personally, I suggest you use Java to create a UDP Socket as
    in: -
    http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24

    You then subscribe to a service using Ajax or TCP/IP and tell them your Port
    Number and IP Address. (UDP involves sequence checking, heartbeats, and
    duplication detection) When you get an asynchronous message that requires
    further action then you once again use the TCP/IP stream (or Ajax) to
    perform the normal PULL transaction.Wrap it all up in IPsec and you're good
    to go!

    Cheers Richard Maher

    PS. As mentioned in that thread/discussion, if you are using multicasting
    then you can drop the "subscribe" step altogether and just subscribe to the
    multicast group in the client. (Sandbox rules and certificates
    notwithstanding.)
    Richard Maher, May 19, 2009
    #9
  10. Martin

    Martin Guest

    On Tue, 19 May 2009 08:12:50 +0800, "Richard Maher"
    <> wrote:


    >If you just want a connection-oriented TCP/IP Java Socket example with one
    >server thread or process per client, then there are many Java examples on
    >the web. One such example is: -
    >http://manson.vistech.net/t3$examples/demo_client_web.html


    Yes, a connection-oriented TCP/IP socket is what I'm looking for. The
    link you provided is prompting for a userid and password so I can't
    get to whatever is there.

    I tried going to: manson.vistech.net but... Yikes, what is that?!

    >All Java source code is in:
    >http://manson.vistech.net/t3$examples/
    >Warning: That code's a bit old now and optimistic in that it doesn't loop
    >around until a "complete" message has been read.
    >
    >But again, personally, I suggest you use Java to create a UDP Socket as
    >in: -
    >http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24


    >You then subscribe to a service using Ajax or TCP/IP and tell them your Port
    >Number and IP Address. (UDP involves sequence checking, heartbeats, and
    >duplication detection) When you get an asynchronous message that requires
    >further action then you once again use the TCP/IP stream (or Ajax) to
    >perform the normal PULL transaction.Wrap it all up in IPsec and you're good
    >to go!
    >
    >Cheers Richard Maher
    >
    >PS. As mentioned in that thread/discussion, if you are using multicasting
    >then you can drop the "subscribe" step altogether and just subscribe to the
    >multicast group in the client. (Sandbox rules and certificates
    >notwithstanding.)
    >


    I don't think there's any need for me to get into UDP or multi-casting
    and the like.

    I did not mention in my original post, but my situation is rather
    simple. This user interface system operates only on an inTRAnet (not
    on the internet). There will seldom be multiple users accessing pages
    simultaneously - and even when that occurs, it would be very unlikely
    to have more than 2 or 3 users at a time.

    What I think I want is just to have a client-side socket that I can
    send out in the page and, in the pageLoad event have it connect back
    to a server-side socket. Then have it raise a "dataArrival" event when
    data comes in and make the data available such that I can display it
    using Javascript.

    Another reason I want to stay with the socket concept is that I can
    have the client connect directly to my interface process and get it's
    data that way. IOW, my server-side scripts don't even need to get
    involved with this.
    Martin, May 19, 2009
    #10
  11. Hi Martin,

    "Martin" <> wrote in message
    news:...
    > On Tue, 19 May 2009 08:12:50 +0800, "Richard Maher"
    > <> wrote:
    >
    >
    > >If you just want a connection-oriented TCP/IP Java Socket example with

    one
    > >server thread or process per client, then there are many Java examples on
    > >the web. One such example is: -
    > >http://manson.vistech.net/t3$examples/demo_client_web.html

    >
    > Yes, a connection-oriented TCP/IP socket is what I'm looking for. The
    > link you provided is prompting for a userid and password so I can't
    > get to whatever is there.


    If you're still curious use: -
    Username: TIER3_DEMO
    Password: QUEUE

    But there should be a directory listing at the other URL I gave you: -
    http://manson.vistech.net/t3$examples/
    >
    > I tried going to: manson.vistech.net but... Yikes, what is that?!


    It's VMS box (a crappy old hobbyists' one but still.) You see long, long ago
    in a land far, far away there lived VMS. . .never mind.

    You can ignore the server code as it makes no difference, just look at the
    ..Java, .JS, and .HTML files.

    >
    > >All Java source code is in:
    > >http://manson.vistech.net/t3$examples/
    > >Warning: That code's a bit old now and optimistic in that it doesn't loop
    > >around until a "complete" message has been read.
    > >
    > >But again, personally, I suggest you use Java to create a UDP Socket as
    > >in: -
    > >http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24

    >
    > >You then subscribe to a service using Ajax or TCP/IP and tell them your

    Port
    > >Number and IP Address. (UDP involves sequence checking, heartbeats, and
    > >duplication detection) When you get an asynchronous message that requires
    > >further action then you once again use the TCP/IP stream (or Ajax) to
    > >perform the normal PULL transaction.Wrap it all up in IPsec and you're

    good
    > >to go!
    > >
    > >Cheers Richard Maher
    > >
    > >PS. As mentioned in that thread/discussion, if you are using multicasting
    > >then you can drop the "subscribe" step altogether and just subscribe to

    the
    > >multicast group in the client. (Sandbox rules and certificates
    > >notwithstanding.)
    > >

    >
    > I don't think there's any need for me to get into UDP or multi-casting
    > and the like.
    >
    > I did not mention in my original post, but my situation is rather
    > simple. This user interface system operates only on an inTRAnet (not
    > on the internet). There will seldom be multiple users accessing pages
    > simultaneously - and even when that occurs, it would be very unlikely
    > to have more than 2 or 3 users at a time.


    Then I suggest just using iNETD and one process/user and keep it simple.

    >
    > What I think I want is just to have a client-side socket that I can
    > send out in the page and, in the pageLoad event have it connect back
    > to a server-side socket. Then have it raise a "dataArrival" event when
    > data comes in and make the data available such that I can display it
    > using Javascript.


    For that you'll need a seperate thread in the Applet similar to the one
    discussed in: -
    http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24
    Just TCP/IP instead of UDP. Heaps of other examples on Google, SUN Tutorials
    etc.

    >
    > Another reason I want to stay with the socket concept is that I can
    > have the client connect directly to my interface process and get it's
    > data that way. IOW, my server-side scripts don't even need to get
    > involved with this.


    Sounds good.

    Cheers Richard Maher.
    Richard Maher, May 19, 2009
    #11
  12. Martin

    Ricardo Guest

    On 18 maio, 18:27, David Mark <> wrote:
    > On May 18, 4:15 pm, Jorge <> wrote:
    >
    > > On May 18, 8:48 pm, David Mark <> wrote:

    >
    > > > (...)
    > > > It's not the ideal choice
    > > > for most cases.

    >
    > > It might not be "ideal", but it works in ~ any browser and doesn't
    > > require VB, Java, Flash nor SilverLight.

    >
    > Nothing I have recommended requires any of those either.  Your pseudo-
    > code demonstrates the LCD of the remaining choices.  And it will not
    > work in any browser.


    And it's not real-time either, just polling.

    Martin, check out Comet as per David's advice: http://lmgtfy.com/?q=javascript comet
    Ricardo, May 19, 2009
    #12
  13. Martin

    Jorge Guest

    On May 19, 8:34 pm, Ricardo <> wrote:
    >
    > And it's not real-time either, just polling.


    That's not polling, meu filho.

    --
    Jorge.
    Jorge, May 19, 2009
    #13
  14. Martin

    David Mark Guest

    On May 19, 6:08 pm, Jorge <> wrote:
    > On May 19, 8:34 pm, Ricardo <> wrote:
    >
    >
    >
    > > And it's not real-time either, just polling.

    >
    > That's not polling, meu filho.


    If it looks like a duck, walks like a duck and quacks like a duck...
    it's probably a duck. You are polling, whether you realize it or not.
    David Mark, May 19, 2009
    #14
  15. Martin

    Jorge Guest

    On May 20, 12:20 am, David Mark <> wrote:
    > On May 19, 6:08 pm, Jorge <> wrote:
    >
    > > On May 19, 8:34 pm, Ricardo <> wrote:

    >
    > > > And it's not real-time either, just polling.

    >
    > > That's not polling, meu filho.

    >
    > If it looks like a duck, walks like a duck and quacks like a duck...
    > it's probably a duck.  You are polling, whether you realize it or not.


    No, there aren't any timers involved there's ~permanently an open
    channel through which the server can send the data as-it-happens, in
    real time, and that's not the same thing as querying (polling) the
    server at regular intervals.

    --
    Jorge.
    Jorge, May 19, 2009
    #15
  16. Martin

    David Mark Guest

    On May 19, 6:43 pm, Jorge <> wrote:
    > On May 20, 12:20 am, David Mark <> wrote:
    >
    > > On May 19, 6:08 pm, Jorge <> wrote:

    >
    > > > On May 19, 8:34 pm, Ricardo <> wrote:

    >
    > > > > And it's not real-time either, just polling.

    >
    > > > That's not polling, meu filho.

    >
    > > If it looks like a duck, walks like a duck and quacks like a duck...
    > > it's probably a duck.  You are polling, whether you realize it or not..

    >
    > No, there aren't any timers involved there's ~permanently an open
    > channel


    It's not permanent per your pseudo-code.

    > through which the server can send the data as-it-happens, in
    > real time, and that's not the same thing as querying (polling) the
    > server at regular intervals.


    http://en.wikipedia.org/wiki/Comet_(programming)#XMLHttpRequest_long_polling

    HTH.
    David Mark, May 19, 2009
    #16
  17. Martin

    Jorge Guest

    On May 20, 12:52 am, David Mark <> wrote:
    > On May 19, 6:43 pm, Jorge <> wrote:
    >
    > > On May 20, 12:20 am, David Mark <> wrote:

    >
    > > > On May 19, 6:08 pm, Jorge <> wrote:

    >
    > > > > On May 19, 8:34 pm, Ricardo <> wrote:

    >
    > > > > > And it's not real-time either, just polling.

    >
    > > > > That's not polling, meu filho.

    >
    > > > If it looks like a duck, walks like a duck and quacks like a duck...
    > > > it's probably a duck.  You are polling, whether you realize it or not.

    >
    > > No, there aren't any timers involved there's ~permanently an open
    > > channel

    >
    > It's not permanent per your pseudo-code.


    It can't be, unfortunately, that's why I wrote *almost* :
    ~permanently. If the slight "blackouts" in-between consecutive xhrs
    are troubling you, using a bit of intelligence at the server side
    together with a couple of xhrs open in parallel would help to mitigate
    the problem completely.

    > > through which the server can send the data as-it-happens, in
    > > real time, and that's not the same thing as querying (polling) the
    > > server at regular intervals.

    >
    > http://en.wikipedia.org/wiki/Comet_(programming)#XMLHttpRequest_long_...
    >
    > HTH.


    "Polling is sometimes used synonymously with busy-wait polling (Busy
    waiting). In this situation, when an I/O operation is required the
    computer does nothing other than check the status of the I/O device
    until it is ready, at which point the device is accessed. In other
    words the computer waits until the device is ready. Polling also
    refers to the situation where a device is repeatedly checked for
    readiness, and if it is not the computer returns to a different task.
    Although not as wasteful of CPU cycles as busy-wait, this is generally
    not as efficient as the alternative to polling, interrupt driven I/O."

    http://en.wikipedia.org/wiki/Polling_(computer_science)

    The I/O in the code I posted isn't polling, it's driven by
    (onreadystatechange) event(s), because events are the closest thing to
    an interrupt that we have in the JS environment in a browser.

    HTH,
    --
    Jorge.
    Jorge, May 20, 2009
    #17
  18. Martin

    David Mark Guest

    On May 20, 4:50 am, Jorge <> wrote:
    > On May 20, 12:52 am, David Mark <> wrote:
    >
    >
    >
    > > On May 19, 6:43 pm, Jorge <> wrote:

    >
    > > > On May 20, 12:20 am, David Mark <> wrote:

    >
    > > > > On May 19, 6:08 pm, Jorge <> wrote:

    >
    > > > > > On May 19, 8:34 pm, Ricardo <> wrote:

    >
    > > > > > > And it's not real-time either, just polling.

    >
    > > > > > That's not polling, meu filho.

    >
    > > > > If it looks like a duck, walks like a duck and quacks like a duck....
    > > > > it's probably a duck.  You are polling, whether you realize it ornot.

    >
    > > > No, there aren't any timers involved there's ~permanently an open
    > > > channel

    >
    > > It's not permanent per your pseudo-code.

    >
    > It can't be, unfortunately, that's why I wrote *almost* :
    > ~permanently. If the slight "blackouts" in-between consecutive xhrs
    > are troubling you, using a bit of intelligence at the server side
    > together with a couple of xhrs open in parallel would help to mitigate
    > the problem completely.


    Nothing you write troubles me.

    >
    > > > through which the server can send the data as-it-happens, in
    > > > real time, and that's not the same thing as querying (polling) the
    > > > server at regular intervals.

    >
    > >http://en.wikipedia.org/wiki/Comet_(programming)#XMLHttpRequest_long_...

    >
    > > HTH.

    >


    [snip]

    >
    > http://en.wikipedia.org/wiki/Polling_(computer_science)


    Dueling Wiki entries? Which is more appropriate for this discussion?

    >
    > The I/O in the code I posted isn't polling, it's driven by
    > (onreadystatechange) event(s), because events are the closest thing to
    > an interrupt that we have in the JS environment in a browser.


    Nonsense. It already has a name that includes the word "polling."
    Please stop confusing the issue by contradicting that. Thanks.
    David Mark, May 20, 2009
    #18
  19. Martin

    Jorge Guest

    On May 20, 7:12 pm, David Mark <> wrote:
    > (..)
    > Nonsense.  It already has a name that includes the word "polling."
    > Please stop confusing the issue by contradicting that.  Thanks.


    It's easy: you either know what polling is or you don't.

    --
    Jorge.
    Jorge, May 20, 2009
    #19
  20. Martin

    David Mark Guest

    On May 20, 5:48 pm, Jorge <> wrote:
    > On May 20, 7:12 pm, David Mark <> wrote:
    >
    > > (..)
    > > Nonsense.  It already has a name that includes the word "polling."
    > > Please stop confusing the issue by contradicting that.  Thanks.

    >
    > It's easy: you either know what polling is or you don't.


    And in this context, you don't (at least not as the rest of the world
    sees it.) Thanks, "Jorge".
    David Mark, May 20, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. batista
    Replies:
    3
    Views:
    4,524
    matrixfan33
    Sep 4, 2009
  2. flamesrock
    Replies:
    8
    Views:
    434
    Hendrik van Rooyen
    Nov 24, 2006
  3. XyZaa
    Replies:
    0
    Views:
    552
    XyZaa
    Jul 19, 2007
  4. samppi
    Replies:
    27
    Views:
    448
    David A. Black
    Dec 5, 2007
  5. Brian

    Real time converted to Unix time

    Brian, Aug 29, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    376
    James Willmore
    Aug 29, 2003
Loading...

Share This Page