Hello Joel, First of all, sorry for me taking so long to answer, I have been sick over the past few days, and only now recovering.
I am afraid you misunderstood me. What we implemented with the RESTful webservice only let the client on the smartphone register a user and generate the needed databases, so that we could use a secure connection and need not submit the password as plaintext to couchDB. The replication then is done via filters that are defined to only synch those documents back to the user DB on the server that adhere to a specific scheme (Bulletpoint 5 in my original message). The reason we did it this way: If we do not use a master database, then every user has access to all the data that is stored on the server. If we do it like this, we delegate the task of managing the data that is to be replicated to a trusted third party, aka the concierge system at the master database. I am sorry if I sounded like I had some more sophisticated solutions, perhaps even as a plugin to couch, but this is the simplest and most secure way we could devise such a system. @Jeoren: You are absolutely right, filtered replication is is the easiest way to do it, but keep in mind that a three-tiered database structure is a must if you want to synch data between multiple users, because of the permission system in couch. I hope to have cleared this up a little, regards, Philipp 2011/4/25 Jeroen van Dijk <jeroentjevand...@gmail.com> > > > > > > > > @Philipp : > > > > Could you point us to some more detailed references? Maybe to the copy of > > (an extract of) your thesis? Or even to an implementation of your > > webservices for per-document authorization? > > > > > Having a similar use case, I would also be very interested to read more > about this approach. So far I don't understand why this approach is needed > when it seems one could also use: > http://wiki.apache.org/couchdb/Replication#Filtered_Replication directly. > However, I have no practical experience with this so I would be happy to > hear why that is not feasible. > > Thanks, > Jeroen >
