Benoit, I'm curious about a comment you made earlier (from Nathans half-baked idea) and have a few questions to spawn from it:
``` There is another solution though, replication using a view change and real replication using a view like in rcouch [1]. With the validate_doc_read function [2] you can do that. No need for a background process. Hopefully this will be merged in couchdb. This have been tested on a relatively large scale ``` 1) If I understand the couch docs correctly, using views as replication filters yields no performance benefit. Its just like running plain jane filters. I figure thats why you are mentioning rcouch where the replication source is indexed data. I just want to clarify that I understand this. 2) For each replicator filter, or view that is run, is a single couchjs process spawned to handle evaling the javascript? 3) What if we write our views in erlang and then use those as replication filters? Could we get around the extra overhead of couchjs processes this way? 4) Can filters be erlang, thus getting around extra couchjs process overhead? Thanks for any insight on these newb questions. sb
