3 ms·
Instead of waiting two years, why not implement your own sync service? I know that sounds like snark, but using something like CouchDB and TouchDB can give your
by robterrell 14y ago
Instead of waiting two years, why not implement your own sync service? I know that sounds like snark, but using something like CouchDB and TouchDB can give your users an experience similar to the one promised by iCloud.
- wisty 14y agoThere's also parse.io, which is apparently not as horrible as iCloud. (All sync is horrible. iCould unnecessarily so).
- DeepDuh 14y agoI'm very interested in those two solutions. Does anyone here have some experience about CouchDB/TouchDB on iOS/Android? Specifically: Does it replicate reliably to a CouchDB or Couchbase server? How are conflicts handled? Are there wrappers already available that map to ObjC/Java native data structures, similar to couchdbkit on python?
- greendestiny 14y agoHey yeah I've used TouchDB on iOS quite a bit. It syncs reliably to Couchdb - I actually haven't tried couchbase. Conflicts are handled in the default couchdb way I think - I haven't really touched on this much. TouchDB syncs to native structures that are derived from CouchModel.
- DeepDuh 14y agoGreat, thanks for the helpful info! Oh, one more thing: Did you ever load multiple TouchDBs? I'm thinking the overhead per DB (not per server) should be pretty small, no? Background: I'd like to build an application where I separate entities into multiple couchDBs, partly since it saves me view definition code, partly because it gives me more flexibility for per-document access permissions.
- greendestiny 14y agoYes I have a framework that splits itself into 3 databases and has quite a lot of attachments. There isn't a big overhead as far as I can see. Does couchDB do what you need with per-document access permissions? It seems to be the biggest downside to couchdb is having to do so many workarounds for per-document access permissions.
- DeepDuh 14y agoThat's also my conclusion. However I'm not aware of a DBMS that - is document based - can easily replicate to laptops and embedded devices - has all the security I want, e.g. encryption, per document security - has the bindings I want and/or a new binding can easily be implemented ad-hoc Given the advantages and disadvantages I'm leaning towards CouchDB and rolling my own security wrapper. IMO that's still better than going with an RDBMS and then implementing replication[1]. How do you see this? [1]edit: and also giving up the document based approach, thus not having arbitrary mapping from the get go.
- greendestiny 14y agoI love couchdb for its replication, not only did I use it for a previous company I worked for and still contract with, I'm using it for my 'big idea' project. Once you have data replication you do need some kind of different approach to user/document security - after all they can take the data they have and do anything with it - so you need to treat replication as data input and validate there, like couchDB does. I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
- DeepDuh 14y agooh, so TouchDB maps to sqlite? Does that work generally? Let's say my documents have lists of maps of tuples of lists - will it create the appropriate table structure in sqlite? The use cases I have in mind don't need the DB to scale to more than a few ten thousand users. Should be ok with a two or three replicated nodes I think, from my experience with Lotus Notes.