Jason, thought about your message more systematically.
We have a distinct tradeoff (JS-provided flexibility vs performance), it exists from the beginning of CouchDB. Now, with cluster, we have chance to reduce JS-related impact. For prev versions I can hardly imagine more than, say, 1K simultaneous highly active users per single instance, when JS is actively used. JS just stalls on validates, updates an so on. And if we dared to have lists (especially in awful ACL workarounds), 1K turned to 100-300, even for thick i7. To increase number of users, to scale, I had to have smth in front of (N * CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always task-specific, non-general. With cluster, the problem goes solved in general, and no additional ‘smth’ in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s all. We already have this problem nearly solved, by cluster nature. So why not to extend – dramatically – CouchDB playground? Shared DBs out of the box is badly desired option, as I see. And it‘s a very cheap way to make ALL couchappers happy for a long time ) BR ermouth
