> I'm suspecting here > that you assume that views are created on demand, based on user-input.
No, I understand. > Totally generic object behaviour abstractions > in SQL need something like 8 tables, there's no way this flies :) No, I was talking about the "Stuffing" implementation. All it does is adding a schema-free field to an existing database? I just don't see what it has anything to do with CouchDB? > How? (Assuming you have a use-case in mind, can you explain that?) Again, about the "Stuffing". It doesn't handle the lack of immediate consistency. This is just what I seem to observe here. Everyone praises the schema-free and JSON, but noone keeps the *eventual* consistency in mind? > Again, can you wrap that into a concrete example, I don't quite get what > that mini-RDBMS is and how your understanding of replication ties > into that :) You have to deal with the *eventual* consistency in your applications don't you? And isn't that incredibly hard and expensive? I mean just think about the end user, when he might put something in CouchDB, but not immediatly see it, in fact, it might be gone for a very long time. What interactive application can work with that? > I have another contract about to start for a server app where all the > data is maintained on the client's desktop, previewed with full > functionality, and then replicated to an EC2 instance. This can be > done with traditional databases, but it's trivial with CouchDB, Well, this is trivial with all databases? Just import and export. It's just copying a file. Now imagine two users working on the data. Yes, you have replication built in, so no data gets lost. But you still need to figure out all the merging? Hum.
