However, letting people do these things offline on mobile devices introduces non-trivial problems of its own.
You've now turned your presumably-consistent, probably-IT-department-managed central database into, at best, a hub that's only eventually consistent. Someone's on vacation and made some updates on their phone? Sure, it looks like it was applied. Better hope they get back in cell range or on a network again for long enough to update -- and that they have a way to monitor it and ensure it was successful -- and at this point you're losing at least part of the convenience this was supposed to enable.
You've also now created the necessity for more robust conflict resolution. When you get two people editing the same data in a live web form, you can at least invalidate the second person's update if you're keeping last-updated timestamps. This approach falls on its face in an edit-offline-then-upload model because you now either have to automatically merge changes (yikes), re-create deleted records that were edited (and deal with dead references, yikes), or implement a prompt to get the user to resolve it themselves (unhappy user and yikes).
Of course, you also have to decide who should get how much and which of your data synced, make sure it's secure, and supply some mechanism so that a careless user can't drop his phone while not locked and allow someone remote access. Making sure the data is irretrievable without the phone being unlocked and the user signed in to the app is the least of your worries, but still something to worry about. Plus you have the potential for sensitive user data being distributed to places it shouldn't be, e.g. PCI compliance issues...
I'm sure there are other issues here, but this is not a replacement; with just these issues it's a totally different paradigm. That doesn't mean it's a bad idea, but it definitely will not drop in nicely and take all that awful CRUD out of our internets.
Many of those techniques also apply to merging and conflict resolution of database stuff. In fact, from a certain perspective, the screw cases are a bit easier.
Perhaps the solution isn't sending CRUD mobile, but rather replacing it in some circumstances with more limited, potentially check-in/check-out, simplified and abstracted workflows that make sense in specific situations. Trying to replace it like this in a general sense presents more problems than it solves.
I don't know if anything like Datomic exists on mobile; and OP is talking about mobile apps not webapps; so OP may be kind of correct, at least today.
Zumero could also be described as having similar characteristics as Git. It's like a DVCS, except for stuff that looks like rows and columns instead of stuff that looks like directories and files.
I'm sure that any decentralized database violates ACID in some way, but Zumero is pretty darn ACIDic. All the local CRUD operations are ACID. And the sync to the server is ACID, or highly corrosive at minimum. But yes, the two operations are separate.
This is perfect timing for me.
Thx.
For instance for me, deleting a task meant anything else regarding that task later was disregarded, it's deleted. Updates to tasks were treated by timestamp. For creating tasks, I had to have a temporary id that I updated after syncing, to a permanent id.
tldr; queue, precedence rules and timestamps.
I get the point OP is trying to make but it really depends on what you are trying to build.
What I really want is a meta framework that runs rails/django for backend + angular/ember for frontend + cordova/phonegap for mobile + responsive display with HTML/JS/CSS + something for syncing to allow offline mobile. Ideally this would be loosely coupled so you could choose your components (i.e. write a native mobile app if you want, or do the backend with Go, etc.)
The two pieces still missing are the sync component and the glue that keeps you from having to define the same thing multiple times. Unless there's something open source I'm unaware of.
SQLite does have excellent support for using multiple database files together (using ATTACH), so there is plenty of opportunity for setting things up to ensure that each device only syncs the data it needs.
OP should market this to devs focusing on countries where mobile networks stink.
That said, I'd love it if more of my apps worked offline with sync.
So many apps, HTML5 or native, could benefit from an offline sync story. That wheel doesn't need to be re-invented over and over again.
This reminds me a lot of WebSQL, which I've always been sad was killed.
We have use cases where mobile devices may be offline for minutes at a time (in hotels and conference halls where wireless is either sketchy or un-usably slow). I can definitely see us using this. I may check out the Couch thing as well, although we use Cassandra for NoSQL scenarios.
