Q: writing a web chat room--sharing info?

ruby-talk
1

New to Ruby, and haven't tried anything like this before.

I'd like to write a web page that acts like a "chat room". (Actually,
I'd like to write a game that incorporates the chat room idea, but first
things first.) Nothing unusual here: a big window that shows what other
people have typed, and a small textbox below where you can type your own
messages. This can be done with ajax, there are some examples on the web
(but not Ruby ones, that I found anyway).

I'm not sure what the best way to share info between the different web
users is. There are several possibilities I can think of: use a text
file, use a database, write a daemon, use memcache.

I'm leaning toward using a database at this point because 1) there won't
be issues finding hosting if I use a db, and 2) I have experience with
databases, unlike daemons and memcache. Still, it seems like overkill to
go in and out of a database when all I really want is shared access to an
array.

Does anybody have a better idea, or other suggestions?

Also, a completely unrelated question for those who read this far. I
notice there seem to be two competing Ruby conventions for naming
methods. My copy of the Pickaxe book (first edition) uses
mixedCaseNaming. Other sources (Ruby itself, frex) use
underscore_naming. Is one of these prevalent, or is it whichever you
like better?

Thanks for any advice,

Matt

2

I was thinking about how to do a chat room like this. The conclusion I reached was that if I had the page "refreshing" every second to display new messages, it would create a high load on the server, each of my rails requests typically takes an entire second to process, so my solution was to write the chat conversation to an html file in a folder in the web root where mod_rewrite was disabled and that way the web server could serve the file with haste and free the web server from unnecessary processing.

-Jeff

···

----- Original Message ----- From: "Matt C" <canimal@invalid.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Wednesday, June 22, 2005 11:40 AM
Subject: Q: writing a web chat room--sharing info?

New to Ruby, and haven't tried anything like this before.

I'd like to write a web page that acts like a "chat room". (Actually,
I'd like to write a game that incorporates the chat room idea, but first
things first.) Nothing unusual here: a big window that shows what other
people have typed, and a small textbox below where you can type your own
messages. This can be done with ajax, there are some examples on the web
(but not Ruby ones, that I found anyway).

I'm not sure what the best way to share info between the different web
users is. There are several possibilities I can think of: use a text
file, use a database, write a daemon, use memcache.

I'm leaning toward using a database at this point because 1) there won't
be issues finding hosting if I use a db, and 2) I have experience with
databases, unlike daemons and memcache. Still, it seems like overkill to
go in and out of a database when all I really want is shared access to an
array.

Does anybody have a better idea, or other suggestions?

Also, a completely unrelated question for those who read this far. I
notice there seem to be two competing Ruby conventions for naming
methods. My copy of the Pickaxe book (first edition) uses
mixedCaseNaming. Other sources (Ruby itself, frex) use
underscore_naming. Is one of these prevalent, or is it whichever you
like better?

Thanks for any advice,

Matt

3

Matt C said:

Does anybody have a better idea, or other suggestions?

I think a database is the best approach. That way you have built-in
archiving of the chats (which is a nice feature, though maybe not needed),
as well as all the other things you get with a database.

This sounds like a neat idea, BTW, and I bet it wouldn't be too hard with
Rails and Ajax.

The only issue is that since web browsers are pull-based (i.e. you can't
really push content to them from a server), you will have to refresh the
"chat window" fairly frequently with HTTP requests (probably
XmlHttpRequests using Ajax.) If you made the process for refreshing as
efficient as possible and only included the changes (through some kind of
"was last updated on" functionality), it shouldn't be too bad of a load on
the server.

Also, a completely unrelated question for those who read this far. I
notice there seem to be two competing Ruby conventions for naming
methods. My copy of the Pickaxe book (first edition) uses
mixedCaseNaming. Other sources (Ruby itself, frex) use
underscore_naming. Is one of these prevalent, or is it whichever you
like better?

I think the "standard" is underscore_naming because, as you said, that is
what the core Ruby classes use. That is also what I prefer, but mostly
because that is also what I use at work in Java (at least for member
variables), so I'm used to it.

Ryan

4

When I wrote one, this is what I did - using a database.

I set up two conversations, using a foreground and background window.

The foreground window loaded, opened the background window, and presented a simple form to the user. On clicking send, the content was POSTed using javascript. The server added the line to the conversation, and returned a null reply (so the window remained without the users input!).

The background window asked for the conversation from message X, using GET.

When this came back it was added to the foreground panel using javascript. And the background window asked for the next (from X+1). It could receive multiple lines.

The server handling the requests would sleep for (iirc) 2 seconds, and look, sleep 2 and look, before finally giving a "there are 0 lines to add" reply every 10 seconds or so. If it found lines to add these were returned as soon as seen.

Result was user updates within at most 2 seconds, plus transit times - it felt responsive.

Resulting server load was remarkably light. A conversation with 50 scripts all chatting 1 line per second, hardly made any impression on the CPU usage on my 500MHZ firewall acting as server. It filled log files though.

If I did it again, I would use an ipanel and httprequest, but the same method, thus avoiding pop-up blockers which sometimes caused me a problem.

You cannot keep the thread running in the server, indefinitely for two reasons: first your hosting company will kill it after a few minutes as a runaway, and second, the user's browser will give up waiting if there is no response.

Hope this give you some ideas.

Regards

Ian

···

In message <Xns967D82805B0FBcanimal@68.12.19.6>, Matt C <canimal@invalid.com> writes

New to Ruby, and haven't tried anything like this before.

I'd like to write a web page that acts like a "chat room". (Actually,
I'd like to write a game that incorporates the chat room idea, but first
things first.) Nothing unusual here: a big window that shows what other
people have typed, and a small textbox below where you can type your own
messages. This can be done with ajax, there are some examples on the web
(but not Ruby ones, that I found anyway).

I'm not sure what the best way to share info between the different web
users is. There are several possibilities I can think of: use a text
file, use a database, write a daemon, use memcache.

I'm leaning toward using a database at this point because 1) there won't
be issues finding hosting if I use a db, and 2) I have experience with
databases, unlike daemons and memcache. Still, it seems like overkill to
go in and out of a database when all I really want is shared access to an
array.

Does anybody have a better idea, or other suggestions?

--
Ian - posting to a Newsgroup. Please remove everything to reply.

5

Matt C wrote:

Also, a completely unrelated question for those who read this far. I notice there seem to be two competing Ruby conventions for naming methods. My copy of the Pickaxe book (first edition) uses mixedCaseNaming. Other sources (Ruby itself, frex) use underscore_naming. Is one of these prevalent, or is it whichever you like better?

The 2nd edition uses underscore_naming (a.k.a. "what God intended" :slight_smile: throughout.

6

Thanks to everyone who replied. Sounds like a database is the way to go.
I imagine I'll be back with more questions in a while.

Matt