Hey, have you ever seen this thing called etherpad? it's pretty great. Some guys even took the research put into that and made a library anyone can use called shareJS[1]. It uses operational transforms, and yes, they're pretty hairy.. but they've been done, and now anyone can use that work.
Then you have the persistent data structures from clojure. Now I might be crazy, but it seems to me that those data structures are probably the most valuable contributions that language has made to our craft, and make the sort of things you're talking about-- not trivial, but a lot easier.
The whole trick is you have to start thinking 4-dimensionally- Which is difficult because our programming languages tend to have modify-in-place mutable state, when what we should have is variables that remember what they were at specific times, and algorithms that are able to merge conflicts seamlessly- not by locking but by recreating what would have happened if the two events had happened synchronously on the same system.
But then, you only really have to do that if what you're talking about is a multiuser system. You can do all this much easier if what you're willing to build is a simpler system. One that works like a one page JS app- JUST LIKE A DESKTOP APP, and only talks to the server at the point of "saving" or "synchronising" or whatever you want to call it. That's easy. You just program undo just like you do in a desktop app, and what you save to the server is a serialised history.
On the server, you have your git-like versioned databases for maximum undo. We know this can work because dropbox does it. If I delete a file on my machine... like REALLY delete it, dropbox still has it for 30 days.
Wikipedia articles have "infinite" undo.
And that's all web. that's all internats.
Fundamentally, once you have javascript, the html5 appcache, localStorage, what is the difference between the "web app" and the "native app" other than performance and some other native features irrelevant to undo?
the mobile apps still have to phone home to a server too now. Half the apps on the app store don't work without a net connection. What is the actual difference?
In fact, you could write a whole app that just downloads to the phone, runs entirely locally, doesn't talk to the server after the initial download, and runs in a browser. Why couldn't you have undo in that?
Well, why not. so I added it to my app pix.pe[2] when you press the back button. not exactly the most impressive example since you don't have much state to store... but what's the difference between doing it there, and doing the same thing in a native app? it's all just turing complete language code, with a storage mechanism and a way to draw on screen. Once you have those things there's nothing to stop you. Other than undo itself being kind of difficult already, regardless of what platform you're writing into.
Then you have the persistent data structures from clojure. Now I might be crazy, but it seems to me that those data structures are probably the most valuable contributions that language has made to our craft, and make the sort of things you're talking about-- not trivial, but a lot easier.
The whole trick is you have to start thinking 4-dimensionally- Which is difficult because our programming languages tend to have modify-in-place mutable state, when what we should have is variables that remember what they were at specific times, and algorithms that are able to merge conflicts seamlessly- not by locking but by recreating what would have happened if the two events had happened synchronously on the same system.
But then, you only really have to do that if what you're talking about is a multiuser system. You can do all this much easier if what you're willing to build is a simpler system. One that works like a one page JS app- JUST LIKE A DESKTOP APP, and only talks to the server at the point of "saving" or "synchronising" or whatever you want to call it. That's easy. You just program undo just like you do in a desktop app, and what you save to the server is a serialised history.
On the server, you have your git-like versioned databases for maximum undo. We know this can work because dropbox does it. If I delete a file on my machine... like REALLY delete it, dropbox still has it for 30 days.
Wikipedia articles have "infinite" undo.
And that's all web. that's all internats.
Fundamentally, once you have javascript, the html5 appcache, localStorage, what is the difference between the "web app" and the "native app" other than performance and some other native features irrelevant to undo?
the mobile apps still have to phone home to a server too now. Half the apps on the app store don't work without a net connection. What is the actual difference?
In fact, you could write a whole app that just downloads to the phone, runs entirely locally, doesn't talk to the server after the initial download, and runs in a browser. Why couldn't you have undo in that?
Well, why not. so I added it to my app pix.pe[2] when you press the back button. not exactly the most impressive example since you don't have much state to store... but what's the difference between doing it there, and doing the same thing in a native app? it's all just turing complete language code, with a storage mechanism and a way to draw on screen. Once you have those things there's nothing to stop you. Other than undo itself being kind of difficult already, regardless of what platform you're writing into.
[1]: http://sharejs.org/ [2]: http://pix.pe/