
Realtime Chat on CouchDB - nexneo
http://damienkatz.net/2009/05/realtime_chat_on_couchdb.html
======
antirez
This does not matter. I'm author of another KV store (Redis), but years ago
got real-time chat working with MySQL, check this:

<http://w.ebchat.com/channel/hackernews>

You can do it with MySql, or with _files_ in append mode with "message_id -
message", and everything else.

I think that KV stores are great, but if you create a false sense of coolness
this is going to hurt in the long run. It is important to show people _why_
really new forms of DBs can be useful and important.

edit: If the point is instead the fact that the DB talks directly HTTP, the
w.ebchat.com chat PHP layer is ridiculous, just a wrapper that takes
parameters from the HTTP side and run a query returning back the data. I can
only see the HTTP protocol as interface to KV DB as a good way to lost a lot
of performances without a reason.

~~~
daleharvey
you wrote a chat with apache and ruby sitting in front of it, the novelty of
this is that there is 2 layers, couchdb, and javascript

~~~
swombat
Separation of concerns is a _GOOD_ thing.

Anyone can write a big-ball-of-mud codebase with only one layer.

~~~
daleharvey
the scripting layer has very little concern in the traditional web model,
there are clear advantages to having that work done in the browser, hence the
popularity of things like ajax and jquery.

why is creating any trivial website backed by a cms that isnt cuttie cooker
blogger template still the domain of the ruby / phpist, we have had plenty of
time to solve these problems with the traditional browser > php/ruby > mysql
model, time for someone to come along with something new.

------
larrykubin
It's like everyone is inventing IRC all over again.

~~~
axod
Now there's an idea, mind if I use it?

------
DougBTX
I have to say I was expecting more content for a top link.

------
swombat
Who exactly is voting this up? C'mon, this isn't news. Would it deserve a #1
HN slot if I got some real-time chat working with Ruby and MySQL? No.

~~~
nexneo
#1 If you get real-time chat working with MySql alone.

~~~
petercooper
Totally possible. Set up a MySQL server with a public username and password,
define some stored procedures to keep the API simple. Share the procedures and
invite people to connect using any MySQL client.

~~~
nexneo
"...invite people to connect using any MySQL client."

That is useful.

~~~
petercooper
That the HTTP-powered Web browser is a universally popular piece of software
has no relevance on its effectiveness. Chatting through a Web browser is as
formally arbitrary as chatting through any other sort of client.

------
Tichy
Does this mean CouchDB already supports Comet? That would really excite me. I
am not aware of any established Comet frameworks, and custom solutions in
Erlang seem to become a common way to go at the problem (because of the cheap
threads, useful to listen to all the connections). Since CouchDB is written in
Erlang, I was hoping that it would support Comet eventually.

Edit: in the chat it was claimed that CouchDB supports COMET. If true, this
would be way cool!

------
axod
Sorry to anyone who was there when I broke it. I forgot it would do _lots_ of
alerts.

Apologies :/ I was just playing :(

------
christofd
Doesn't guard against sending Javascript: my browser was killed with popups -
ANGER!!!

~~~
nexneo
Its not finished chat product. Its more a demo of what can be accomplished
with DB that talks http. See, <http://github.com/jchris/couchapp/tree/master>

------
axod
Fun :) but using a DB for chat is a really bad idea.

~~~
juliend2
Why is it a bad idea to use a DB for a chat?

~~~
axod
Chat is a messaging system. Sending messages from one user, to other users. A
database is a ridiculous way to do that.

~~~
CalmQuiet
What's a better way to keep a log, if desired?

~~~
axod
Chat history should be a separate, non-critical path.

~~~
daleharvey
chat history for you should be on a seperate, non critical path,

sometimes the auditability of being able to say you sent the message is as
important as sending the message itself, banking / telecoms etc.

sometimes you want to search your logs in "real time", ala twitter search

and as I alluded to above, more than often message delivery should be done
seperate to persistence, but that doesnt strictly mean outside of a database.

~~~
moe
_sometimes the auditability of being able to say you sent the message is as
important as sending the message itself, banking / telecoms etc._

You keep intermixing a user-to-user chitchat system (which the submitter
presented) with banking and telco applications. They are not the same, they
are not even closely related. ISO 15022 does not apply to twitter.

