I resent being called "smelly". And I WISH I was 15 again ;) >> "But what none of these detractors seem to understand (except for the script-kiddies) is that t

I resent being called "smelly". And I WISH I was 15 again ;) >> "But what none of these detractors seem to understand (except for the script-kiddies) is that the important thing about this demo is the web. CouchDB is part of the web, and serves web applications natively." Yeah ok, CouchDB includes a web server :/ why is that a good thing? Less scaling options when things are bundled together like that. >> "The second set of detractors say realtime applications shouldn't go to disk, because it's slow and a lot of data. To them I say "disk is free"." The only reason a real time messaging system should go to disk, is if persistent logs are required. And in that instance, when you scale, it most certainly is not free. >> "Call me when performance matters." Here's a little story. I built the predecessor to Mibbit using php and mysql. It took a long time. It didn't scale so well. I knew using a db was a stupid idea, but I wanted to see just how stupid. I started using shared memory, semaphores, message queues etc instead. It scaled a bit better, but still lame. In the end I decided to scrap it, and rewrite it from scratch in something I knew would scale. It now does about 2 billion messages a month or something. You should think about scaling from the outset. Having to scrap everything and change language/architecture/etc is kindof a pain. Just because there's some "new" "so hot right now!!!" language/framework/etc out there, it's probably totally the wrong tool for the job. The traffic going back and forth from the browser to the demo CouchDB chat couldn't have been less efficient if it tried - it was sending all 50 recent lines of chat every single time. I don't know if that's easily fixed, probably not. Maybe you'd have to delve into CouchDB code :/ I hate this trend of "Less code.. more ease for the developer.." etc. Focus on the user and what they want, and how you can best give it to them. Not what's least lines of code/easiest for you.