3 ms·

Does anyone know if they have CouchDB on iOS, Android, or even on the browser? Last I checked, they didn't, and only had experimental builds on each. To me, th

by iamwil 15y ago

Does anyone know if they have CouchDB on iOS, Android, or even on the browser? Last I checked, they didn't, and only had experimental builds on each. To me, that'd be a much more compelling reason to use CouchDB, since syncing between server and client is a pain, and having CouchDB on both servers and client would make development life much easier for me. If not, then publish the replication protocol. I tried looking for it once, and only found scant information on the mailing lists and documentation.

shadowmatter 15y ago
I found the following two documents on the replication protocol: http://www.dataprotocols.org/en/latest/couchdb_replication.html http://www.dataprotocols.org/en/latest/couchdb_replication.h... https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... From the end of http://wiki.apache.org/couchdb/Replication http://wiki.apache.org/couchdb/Replication
- tilgovi 15y ago
  Nice! I didn't realize so much had been done on dataprotocols.org yet!
daleharvey 15y ago
Couchbase mobile is the CouchDB server running on android and ios, it works and is a released product by Couchbase, they are also planning to supercede these with native implementations (TouchDB for iOS and Android) While building TouchDB Jens documented the replication protocol here: https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... I am working on (actually am right now) the in browser implementation of CouchDB called PouchDB (https://github.com/mikeal/pouchdb https://github.com/mikeal/pouchdb) it is nearing a beta release.
- robterrell 15y ago
  Hooray, been hacking on the upstream PouchDB myself, glad to hear you've got it far along!
  - daleharvey 15y ago
    Awesome, got a url? the more working on this the merrier :)
tilgovi 15y ago
PouchDB is ready for some testing and play. Dale Harvey has put a lot of work into it recently: https://github.com/daleharvey/pouchdb https://github.com/daleharvey/pouchdb I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together. A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.
- tftf 15y ago
  I just wrote a Backbone Sync Adapter for PouchDB: https://github.com/jo/backbone-pouchdb https://github.com/jo/backbone-pouchdb Its very basic but has a working Todo example.
jchrisa 15y ago
If you are interested in Couch-like magic in the mobile context, we've got an active mailing list for TouchDB and other mobile projects here: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase
nupark2 15y ago
The problems on mobile are so incredibly different than server, I don't see that CouchDB would be useful client-side. The focus client-side is on speed, battery-life, ease of programming, and perhaps most of all, maintaining separation of concerns between the server-side data model and the client data model. The server must be free to evolve independently of the client, and many remote clients will run legacy versions of your software for extended periods of time. Moreover, rarely is data distribution sufficient to model high-level interactions between client and server, which is more likely to introduce bugs, complexity, and significantly detract from the long-term maintainability of the client/server protocol. The end result is that you don't particularly benefit from CouchDB client-side, and especially not replication -- you need a well-defined supportable network model.
- jchrisa 15y ago
  Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. This saves battery life, and gives a better user experience as folks aren't waiting for hundreds of milliseconds for request and response to propagate across unreliable mobile networks. As far as the maintainability concerns, it's an interesting point. There are certainly apps which may want to sacrifice the ease of use and performance advantages of having sync done for you, because they have specialized data sharing requirements. But for a whole lot of apps the benefits of sync far outweigh the contraints of having the same data model on the client and server. Some example use cases where sync can simplify programming (or even make a class of apps possible which would be much harder without it): point-of-sale, retail, medical records (doctor with an iPad and limited wifi), military (need that data no matter what). Here's a pdf of the slides I presented yesterday at Chicago's WindyCityGo conference: http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.pdf http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.p...
  - nupark2 15y ago
    > Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. You're just moving the costs around, and likely transmitting far more data than needs be sent. In addition, you're front-loading the transmission of data that users don't need right now. Having built many network-facing mobile applications with exceedingly large user bases, I'm unconvinced. The maintenance complexity, the excess transmission of data, issues of data consistency over time, the lack of integration with client-side business rules without considerable investment in code that significantly replaces the sync logic. I think that the reality of the situation is that in the rare cases you need offline, fully synchronized data, it's not particularly difficult to just download what you need as an atomic unit and save it. The majority of the time, however, on-demand request handling is more efficient, well-defined, and maintainable.

by iamwil 15y ago

shadowmatter 15y ago

I found the following two documents on the replication protocol: http://www.dataprotocols.org/en/latest/couchdb_replication.html http://www.dataprotocols.org/en/latest/couchdb_replication.h... https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... From the end of http://wiki.apache.org/couchdb/Replication http://wiki.apache.org/couchdb/Replication

tilgovi 15y ago
Nice! I didn't realize so much had been done on dataprotocols.org yet!

daleharvey 15y ago

Couchbase mobile is the CouchDB server running on android and ios, it works and is a released product by Couchbase, they are also planning to supercede these with native implementations (TouchDB for iOS and Android) While building TouchDB Jens documented the replication protocol here: https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio... I am working on (actually am right now) the in browser implementation of CouchDB called PouchDB (https://github.com/mikeal/pouchdb https://github.com/mikeal/pouchdb) it is nearing a beta release.

robterrell 15y ago
Hooray, been hacking on the upstream PouchDB myself, glad to hear you've got it far along!
- daleharvey 15y ago
  Awesome, got a url? the more working on this the merrier :)

tilgovi 15y ago

PouchDB is ready for some testing and play. Dale Harvey has put a lot of work into it recently: https://github.com/daleharvey/pouchdb https://github.com/daleharvey/pouchdb I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together. A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.

tftf 15y ago
I just wrote a Backbone Sync Adapter for PouchDB: https://github.com/jo/backbone-pouchdb https://github.com/jo/backbone-pouchdb Its very basic but has a working Todo example.

jchrisa 15y ago

If you are interested in Couch-like magic in the mobile context, we've got an active mailing list for TouchDB and other mobile projects here: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase

nupark2 15y ago

The problems on mobile are so incredibly different than server, I don't see that CouchDB would be useful client-side. The focus client-side is on speed, battery-life, ease of programming, and perhaps most of all, maintaining separation of concerns between the server-side data model and the client data model. The server must be free to evolve independently of the client, and many remote clients will run legacy versions of your software for extended periods of time. Moreover, rarely is data distribution sufficient to model high-level interactions between client and server, which is more likely to introduce bugs, complexity, and significantly detract from the long-term maintainability of the client/server protocol. The end result is that you don't particularly benefit from CouchDB client-side, and especially not replication -- you need a well-defined supportable network model.

jchrisa 15y ago
Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. This saves battery life, and gives a better user experience as folks aren't waiting for hundreds of milliseconds for request and response to propagate across unreliable mobile networks. As far as the maintainability concerns, it's an interesting point. There are certainly apps which may want to sacrifice the ease of use and performance advantages of having sync done for you, because they have specialized data sharing requirements. But for a whole lot of apps the benefits of sync far outweigh the contraints of having the same data model on the client and server. Some example use cases where sync can simplify programming (or even make a class of apps possible which would be much harder without it): point-of-sale, retail, medical records (doctor with an iPad and limited wifi), military (need that data no matter what). Here's a pdf of the slides I presented yesterday at Chicago's WindyCityGo conference: http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.pdf http://dl.dropbox.com/u/14074521/syncpoint-windycity-small.p...
- nupark2 15y ago
  > Speed, battery-life, ease of programming are 3 of the main reasons we are motivated to build a Couch-compatible storage and sync layer on the device. If you have an intelligent sync solution, you can use significantly less radio time to present the same features. You're just moving the costs around, and likely transmitting far more data than needs be sent. In addition, you're front-loading the transmission of data that users don't need right now. Having built many network-facing mobile applications with exceedingly large user bases, I'm unconvinced. The maintenance complexity, the excess transmission of data, issues of data consistency over time, the lack of integration with client-side business rules without considerable investment in code that significantly replaces the sync logic. I think that the reality of the situation is that in the rare cases you need offline, fully synchronized data, it's not particularly difficult to just download what you need as an atomic unit and save it. The majority of the time, however, on-demand request handling is more efficient, well-defined, and maintainable.