drb for ajax based chat?

rubyonrails-talk
1

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

2

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

3

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

Thanks, Pratik

4

Jason Roelofs 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.

5

Channer Teomond 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!)

6

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?

7

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.

Cheers-

-- Ezra Zygmuntowicz-- Lead Rails Evangelist -- ez@engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)