what i am trying to do is similar to syncpoint. effectively couchdb is the api-message-carrier. The idea of database-as-security-domain also fits perfectly - users would see/replicate only dbs that they belong to. But - N users working in M databases means listening to N+M changes-feeds and post-processing them.
lumping all in one db, and filtering that into internally-filtered partial replications (a filter per user) seems ... rather tricky. can a client-replicator talk to http-proxy that looks like normal couchdb but is (invisibly-to-client) routed into a filtered-replication? ah i should think how these can scale too.. svil On Sun, 7 Oct 2012 09:27:18 +0200 Dave Cottlehuber <[email protected]> wrote: > On 7 October 2012 07:59, svilen <[email protected]> wrote: > > g'day > > > > i'm going to have thousands of databases. They are all of similar > > kind, but belong to different (groups of) users, so can't be > > bundled into one. And setupping 10000 connections to > > couchdb/dbXXXXX/_changes doesn't seem very neat, even if on same > > machine. > > Not possible today unfortunately. > > Has anybody got any numbers or experience on practical limits of > _changes feeds connections to a single server? > > A+ > Dave
