7 ms·
Realtime Chat on CouchDB
- axod 17y agoFun :) but using a DB for chat is a really bad idea.
- juliend2 17y agoWhy is it a bad idea to use a DB for a chat?
- axod 17y agoChat is a messaging system. Sending messages from one user, to other users. A database is a ridiculous way to do that.
- juliend2 17y agoGood point. But i wonder how some services like GoogleTalk does the storing of the chat conversations. Maybe flat-files i guess?
- daleharvey 17y agormdb's are a ridiculous way to run a chat application, other databases like mnesia (used heavily for ejabberd) work pretty well. storage and querying are pretty typical functional requirements, I dont know how much more suited couchdb would be for chat than mysql, but you cant dismiss it because of the same preconceptions you have with other "databases"
- moe 17y agoYou are missing the point. If your messages hit the disk, ever, then you are either not implementing a "real-time chat" or you're doing it horribly wrong.
- daleharvey 17y agohit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database if querying history is a functional requirement then your data has to be stored somewhere, filesystem is an easy win, but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? My point wasnt even that couch would be particularly great at these, it was just that most of this "common wisdom" applies towards traditional rbdms, databases can be built with exactly realtime messaging in mind
- moe 17y agohit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database Disk. And it means your data is being written to the disk. if querying history is a functional requirement then your data has to be stored somewhere The stated functional requirement was "real-time chat". If you want to record all messages ever exchanged then you are not talking about a chat system anymore but rather about an archival system. For the latter a database can indeed make sense but the two should not be mixed together due to the fundamentally different requirements. but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? By hitting the disk for each message. databases can be built with exactly realtime messaging in mind And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh.
- daleharvey 17y ago"The stated functional requirement was "real-time chat". I didnt see anyone list a functional requirement specification, I at least, was talking hypothetically. ITs worth noting that chat applications are almost(always?) never real time, they are soft realtime. " two should not be mixed together due to the fundamentally different requirements." Message routing and persistence are not mutually exclusive, they have competing requirements but that does not mean they cannot and do not exist. see twitter, banking, telecoms, campfire, ejabberd. "By hitting the disk for each message." If not hitting this disk is a a functional requirement then fair enough, I have never heard of this being a requirement outside of embedded systems. "And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh." I wouldnt mind knowing exactly what makes "messages" seperate from data. a database is just an abstraction layer over a set data that can provide several completely different benefits for storing and accessing that data, it isnt even required that a database "hits the disk" in the slightest, and there is no part of the definition of "database" that prevents it from being absolutely perfect for messaging systems, it just so happens that all the examples you can think of arent.
- CalmQuiet 17y agoWhat's a better way to keep a log, if desired?
- moe 17y agoopen( 'log', O_CREAT|O_APPEND );
- axod 17y agoChat history should be a separate, non-critical path.
- daleharvey 17y agochat 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 17y agosometimes 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.
- jbarciauskas 17y agoExactly. The trick of real-time chat is the real-time part, i.e. getting the message as close to when the user sent it as possible. Storing chat history is not interesting, we all understand how to post a form to a DB table. The solution to this problem is related to persistent connections to the server or polling the server... Whether the chat is persisted is completely besides the point in the context of a real-time chat demo. So the interesting part of this demo is not CouchDB but the refreshView() function, which uses the long-polling AJAX messaging technique - see http://cometdaily.com/2007/11/15/the-long-polling-technique/ http://cometdaily.com/2007/11/15/the-long-polling-technique/ or just google "Long polling"
- DougBTX 17y agoI have to say I was expecting more content for a top link.
- axod 17y agoSorry to anyone who was there when I broke it. I forgot it would do lots of alerts. Apologies :/ I was just playing :(
- christofd 17y agoDoesn't guard against sending Javascript: my browser was killed with popups - ANGER!!!
- nexneo 17y agoIts 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 http://github.com/jchris/couchapp/tree/master
- deleted 17y ago[deleted]
- swombat 17y agoWho 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 17y ago#1 If you get real-time chat working with MySql alone.
- swombat 17y agoCouchdb isn't a good comparison to mysql - it's got an HTTP interface built in. My point is: It's trivial to put together a chat application with any HTTP backend that's capable of storing and retrieving data. So what's all the excitement about?
- petercooper 17y agoTotally 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 17y ago"...invite people to connect using any MySQL client." That is useful.
- petercooper 17y agoThat 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.
- nexneo 17y agoAt moment its capable of removing middle layer (one less moving part, actually two if you count Apache/Nginx) Some pointers, http://github.com/jchris/couchapp/tree/master http://github.com/jchris/couchapp/tree/master http://books.couchdb.org/relax/hosted-applications http://books.couchdb.org/relax/hosted-applications
- deleted 17y ago[deleted]
- antirez 17y agoThis 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 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 17y agoyou 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 17y agoSeparation of concerns is a GOOD thing. Anyone can write a big-ball-of-mud codebase with only one layer.
- nexneo 17y agoYes, it is good thing. But will that method perfect for every use case. Think about maintaining DB(Mysql, Sql language), Web server(Crazy config files), application server (Ruby or PHP), Client side(Javascript) just for personal blog/site. Here layers are less and Languages(only one) and config files are less. EDIT: "And less is good" , Arguments are endless unless you are talking about specific use case.
- daleharvey 17y agothe 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 17y agoIt's like everyone is inventing IRC all over again.
- axod 17y agoNow there's an idea, mind if I use it?
- Tichy 17y agoDoes 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!