[obviouslygreen]

Aside from being an advertisement, this does make a reasonably decent point for some use cases... though I don't believe most of them are ones that are commonly solved with web-based CRUD.

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.

[ericsink]

Developers used to be afraid of automatic merging and conflict resolution in version control tools. We evolved.

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.

http://zumero.com/docs/zumero_core.html#chapter_conflicts

[chacham15]

Their general idea is very similar to svn vs. git. That use case has proven to be very effective. Im sure that you can find use cases that this is more difficult to apply (where row conflicts cannot be automatically merged) but there are also use cases where this idea works like a gem.

[camus]

So why do you suggest ? dropping any offline/online sync feature because the implications (for crud apps)? i guess you could have a system checking what resource has been updated since last connection and explicitly alerting the user the commit has failed due to an update that happened between the offline edit and the connection, or keep track of all the versions ( which is hard to manage if resources have relationships and depend on other resources ) Anyway that's a subject i'm really into so any resource on the matter is welcomed , i'm really looking for the holy grail of data syncing.

[obviouslygreen]

I think the viable scope of such a replacement is there but probably very limited. In my opinion it depends on the type, format, frequency of editing, sensitivity, and many other properties of the data you're working with.

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.