4 ms·
Hi Jan, another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than th
by nborwankar 14y ago
Hi Jan,
another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than the rate of growth of bandwidth.
So everyone can't always be accessing all their data in the cloud through an always on infinite bandwidth connection.
So you're going to need to carry a subset of your data with you - the subset that's "hot".
Now having said that keeping hot data in sync with the larger data store is a hard problem - p2p or not.
And what these architectures (CouchDB, PouchDB, ...) do is take the sync problem and make it an infrastructure issue so it only has to be solved once by the infrastructure creator (CouchDB team) rather than again and again and again by each app developer who wakes up in the middle of the night and realizes they have to solve "sync" in their app as an application problem. Then they have a nightmare and when they wake up they are babbling.
The additional anti-pattern-badness with sync-in-the-app is that that kind of sync is usually incompatible with another app's bespoke sync. But when sync is in the infrastructure then a much larger group of people who use that infrastructure can share data across apps if they want to without having necessarily to share a schema.
This is the real power of making sync part of the underlying computing fabric.
Finally when this infrastructure is open source the real -danger of lock-in such as when you use Dropbox is mitigated, should you want to have that freedom.
Cheers.