5 ms·

I don't think it's that capable of doing all that. As far as I understand, CouchDB does a "dumb" version-control type synchronization. Server A can copy all the

I don't think it's that capable of doing all that. As far as I understand, CouchDB does a "dumb" version-control type synchronization. Server A can copy all the data that Server B has and do it in a nice clean manner over HTTP. I can think of several disadvantages (though I may be wrong and naive): 1. If you're running a node, and I'm running a node, my data schematics might not be compatible with yours. If I write a uniform backward-compatible RPC, then it'll be a little better. 2. I can't selectively allow you to copy some data (photos) and not others. If you are a user on my database, you can access everything you have permissions to. It's hard to set fine-grained permissions. 3. Push notifications will be hard. I'd have to poll the database for changes. For that matter, the same can be achieved by putting a giant XML file on Git, and having each person set up a remote, or using a complicated set of shell scripts and rsync. Couch's replication facility is really neat, especially if you want to scale horizontally or if you're adding redundancy, etc. CouchDB is becoming the new hammer. It'll get tempting to write source control, file backup, etc, using this database because of the data sync, and decent query capabilities. But I feel that building a social network on top of CouchDB's replication might not be the best of ideas.

daleharvey 16y ago
couchdb has filtered replication so you can selectively choose what gets replicated and it has continous replication with a comet changes feed, so push notifications are also built in. the data schematics are a bit of a non issue, at some point someone needs to agree with what the data format is. basically couchdb already has a lot of this functionality baked in as first class citizens, I agree that there is a lot of situations where people will be hammering couch into a hole that doesnt fit (source control would be a good one), but I certainly dont think this is one of them.
- messel 16y ago
  Yeah I wanted to build a stand alone media sharing app (big data files, images, movies, etc), but now I may not need one. Continuous replication of parts of subscribed databases was the idea I was going to go with.
- maxogden 16y ago
  The data schematics will be implemented via the OStatus protocols. CouchDB's role is to comply with OStatus and push and pull data when necessary. As Dale stated, this is a good fit for Couch's replication mechanisms. Protocols like PubSubHubbub are ripe for porting over to Couch.
janl 16y ago
CouchDB sync is more like rsync than DVCS sync. The idea is that it is very simple, yet powerful enough to build more sophisticated systems on top of. Building small and large P2P systems on top of CouchDB is very much a design goal. The fact that sync can be used to build scalable HA systems is orthogonal. To your points: 1.) I think the idea of this project is to define a common ground to allow seamless sync. 2.) CouchDB supports filtered replication, so you can define what can be synced and what not. 3.) CouchDB has a push-notification changes feed that does not involve polling.
- deleted 16y ago
  [deleted]
- dbfclark 16y ago
  Is it actually the case that filtered replication can be used cleanly for access control now? My understanding from the various docs was that currently you can write a filter but not require that users replicate through it -- that is, if you have permission to replicate, you have permission to replicate and that's it. For real access control using this I think you'd need something like a permission to replicate distinct from permission to read and a permission to replicate only through a specified filter. I suppose I'm off to have a look through Max's source, but if I'm wrong about these things I'd appreciate the correction... ...ok, back. Right now there appears to be no access control at all. Granting that this is a relatively early-stage project so it doesn't necessarily matter too much, but my question still stands.
  - janl 16y ago
    Your personal data db could be private and you could use filtered replication to create a local clone with only the data you want to allow replicating.
- StavrosK 16y ago
  Do you know if this thing will replicate all data of every person in the network? Or does it just connect to your friends' nodes and pull only their own changes?

daleharvey 16y ago

couchdb has filtered replication so you can selectively choose what gets replicated and it has continous replication with a comet changes feed, so push notifications are also built in. the data schematics are a bit of a non issue, at some point someone needs to agree with what the data format is. basically couchdb already has a lot of this functionality baked in as first class citizens, I agree that there is a lot of situations where people will be hammering couch into a hole that doesnt fit (source control would be a good one), but I certainly dont think this is one of them.

messel 16y ago
Yeah I wanted to build a stand alone media sharing app (big data files, images, movies, etc), but now I may not need one. Continuous replication of parts of subscribed databases was the idea I was going to go with.
maxogden 16y ago
The data schematics will be implemented via the OStatus protocols. CouchDB's role is to comply with OStatus and push and pull data when necessary. As Dale stated, this is a good fit for Couch's replication mechanisms. Protocols like PubSubHubbub are ripe for porting over to Couch.

janl 16y ago

CouchDB sync is more like rsync than DVCS sync. The idea is that it is very simple, yet powerful enough to build more sophisticated systems on top of. Building small and large P2P systems on top of CouchDB is very much a design goal. The fact that sync can be used to build scalable HA systems is orthogonal. To your points: 1.) I think the idea of this project is to define a common ground to allow seamless sync. 2.) CouchDB supports filtered replication, so you can define what can be synced and what not. 3.) CouchDB has a push-notification changes feed that does not involve polling.

deleted 16y ago
[deleted]
dbfclark 16y ago
Is it actually the case that filtered replication can be used cleanly for access control now? My understanding from the various docs was that currently you can write a filter but not require that users replicate through it -- that is, if you have permission to replicate, you have permission to replicate and that's it. For real access control using this I think you'd need something like a permission to replicate distinct from permission to read and a permission to replicate only through a specified filter. I suppose I'm off to have a look through Max's source, but if I'm wrong about these things I'd appreciate the correction... ...ok, back. Right now there appears to be no access control at all. Granting that this is a relatively early-stage project so it doesn't necessarily matter too much, but my question still stands.
- janl 16y ago
  Your personal data db could be private and you could use filtered replication to create a local clone with only the data you want to allow replicating.
StavrosK 16y ago
Do you know if this thing will replicate all data of every person in the network? Or does it just connect to your friends' nodes and pull only their own changes?