Drb for ajax based chat?

I have a basic chat application running but I don’t like having to make
the
browser auto check for new messages every so often. I would prefer a
push
scenario where the data is pushed from the server to the client.

would drb make for a good solution to this problem?

I know alot of ajax chat apps use flash to create this push type
application
but I don’t want to use flash if at all possible.

Thanks for any input on weather or not drb would be a good choice or any
other suggestions!

Charlie

You’re comparing apples and oranges here, sorry to say. Drb has nothing
to
do with being able to push data to the client, it’s simply a tool to let
you
run ruby processes outside of the normal http request process. You want
to
push data to the client, you have two options:

  1. Have the client AJAX poll every x seconds.
  2. Have a Flash or Java applet that opens a socket to the server and is
    able
    to process the received data (Juggernaut is great for this, yes it does
    use
    Flash).

I’m currently going the Java applet way because it has very seamless
integration with JavaScript and back, something that Flash has only
recently
got in Flash 8, and who knows when Linux and Mac will ever see that
player.

I think you can use Drb to start the listen server, but that’s about
it.
Check out the Juggernaut plugin, it is exactly what you are looking for.

Jason

http://blog.lingr.com/ has some posts that might be helpful.

Thanks,
Pratik

On 11/28/06, Jason R. [email protected] wrote:

I’m currently going the Java applet way because it has very seamless

Thanks for any input on weather or not drb would be a good choice or any
other suggestions!

Charlie


rm -rf / 2>/dev/null - http://null.in

Dont judge those who try and fail, judge those who fail to try…

Jason R. wrote:

got in Flash 8, and who knows when Linux and Mac will ever see that
player.

I believe Flash Player 8.5 and 8.0 are out for Mac (in Universal binary
format too). And I know that Flash Player 9.0 is in beta for Linux.

Charlie B. wrote:

I have a basic chat application running but I don’t like having to make
the
browser auto check for new messages every so often. I would prefer a
push
scenario where the data is pushed from the server to the client.

Your probably stuck with polling. The only other option is the hack
GTalk I believe uses that never cuts off the connection from the request
and keeps pushing back through that.

Jason R. wrote:

  1. Have the client AJAX poll every x seconds.
  2. Have a Flash or Java applet that opens a socket to the server and is
    able
    to process the received data (Juggernaut is great for this, yes it does
    use
    Flash).

Per my “how to chat” research, a responsive chat application is
primarily an
illusion. (GChat shall go where few dare tread!)

You can’t tell the difference between another chatter taking 15 seconds
to
write a reply, and your own browser taking 15 seconds to deliver it.

The trick to the illusion of responsiveness (per that post) is to send
your
own message back with the reply to the AJAX post that sends your
message. So
a chatter has two AJAX things, a periodical one and a form_remote one.
Both
call the same target action, and both update from the same batch of
JavaScript.

Each time you submit a message, if the message is non-blank, the chatter
action pushes the chat into the database, then fetches any new chat from
the
database, and returns it in the response. The result appears instant,
and
you can’t tell that other people are slow.


Phlip
Redirecting... ← NOT a blog!!!

Channer T. wrote:

One trick to avoid the database is to use memcached. Its much faster
for this kind of thing, but the chat history lives in RAM, not the DB.
The bonus is your not hitting the DB every few seconds.

MySQL?

I’m SQLite3 until further notice. (And major props to _why for fixing
some
silly syntax errors - only by rewriting the driver!)


Phlip
Redirecting... ← NOT a blog!!!

I know you can use drb to create an ajax upload progress bar. It would
seem
that this progress bar is being “pushed” from the server. Is it not?

Phlip wrote:

Each time you submit a message, if the message is non-blank, the chatter
action pushes the chat into the database, then fetches any new chat from
the
database, and returns it in the response. The result appears instant,
and
you can’t tell that other people are slow.

One trick to avoid the database is to use memcached. Its much faster
for this kind of thing, but the chat history lives in RAM, not the DB.
The bonus is your not hitting the DB every few seconds.

On Nov 29, 2006, at 9:20 AM, Charlie B. wrote:

I know you can use drb to create an ajax upload progress bar. It
would seem that this progress bar is being “pushed” from the
server. Is it not?

Nope. It is being polled by the client with javascript. Drb itself

cannot talk directly to the client because it requires ruby on the
other side of the connection to uncode drb calls. So you can use a
drb server to hold state and chat lines in memory in one single place
so that you can have other socket servers that open a push type
connection to the client. Then you have code that takes an incoming
chat line and adds it to the drbserver state and then makes the push
servers push that line to all clients connected to that chat.

What you should look at is juggernought(sic?) It has a socket server

and a rails plugin for working with the socket server for push type
connections.

Also the author of Lighttpd has been writing some interesting stuff

about this topic recently. It looks like he has some cool ideas
coming down the pipe for lighty.

http://blog.lighttpd.net/articles/2006/11/27/comet-meets-mod_mailbox

Cheers-

– Ezra Z.
– Lead Rails Evangelist
[email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)