Tickets and Real-time Response

[A. Shore]

Another capability has been on this so-called mind for some time now,
and it's intended to improve Tickets' real-time response capability.

It's a familiar problem in http-connected situations, with chat being
a good example; with a conventional implementation of a PHP-based
chat, input from user A gets communicated to user B only by a periodic
page refresh. What that period should be will depend on yr particular
environment, but if it's as little as every 10 seconds, then user B
will wait on the average of five seconds before he sees the response.
Kind of mickey-mouse. (Which is why big chat implementations are not
usually based on http.)

In Tickets, we approximate that by an automatic page refresh keyed off
a setting value, and it can be upsetting when it catches you in the
middle of some, say, keyboard input. Users HAVE complained about
this with some legitimacy, IMO.

The technique I've been nibbling around the edges of is related to an
Ajax variation, often referred o as Comet. (Written up at
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
)

It involves a hidden frame (usually) with a 'long poll' based on the
engine behind Ajax, the XMLHttpRequest() function. The client-side
function invokes a server-side script that - as opposed to
conventional Ajax implementations - doesn't respond until it has
determined that it 'has something to say', often as long as several
minutes later. Client-side, the XHR request is satisfied, the
function does its thing (whatever that may be, like refreshing a <div>
with new contents) and then immediately posts another XMLHttpRequest
().

It's not a huge amount of code, but it is kind of tricky, and it's
something I'd like very much to tackle myself, when the press of
getting new stuff out the door allows. <grin>

Thanks for making it this far with me, guys!

Reactions invited.

[AndyH]

Arnie.

I think using Comet is a good idea and I'm totally on board with
letting you handle this one yourself. Good luck with that one.:-)

Cheers
Andy

On May 28, 2:38 am, "A. Shore" <shor...@gmail.com> wrote:
> Another capability has been on this so-called mind for some time now,
> and it's intended to improve Tickets' real-time response capability.
>
> It's a familiar problem in http-connected situations, with chat being
> a good example;  with a conventional implementation of a PHP-based
> chat, input from user A gets communicated to user B only by a periodic
> page refresh.  What that period should be will depend on yr particular
> environment, but if it's as little as every 10 seconds, then user B
> will wait on the average of five seconds before he sees the response.
> Kind of mickey-mouse.  (Which is why big chat implementations are not
> usually based on http.)
>
> In Tickets, we approximate that by an automatic page refresh keyed off
> a setting value, and it can be upsetting when it catches you in the
> middle of some, say, keyboard input.  Users HAVE  complained about
> this with some legitimacy, IMO.
>
> The technique I've been nibbling around the edges of is related to an

> Ajax variation, often referred o as Comet.  (Written up athttp://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications