I can see the possibility of a framework to take away the complexity of the manifest and the online/offline status - but this is most definitely the basis of webOS, or something very similar.
"Downloading an app" is simply going to the web page when you are online initially, and then adding a (possibly automatically) shortcut to the "desktop."
> "Downloading an app" is simply going to the web page when you are online initially, and then adding a (possibly automatically) shortcut to the "desktop."
FWIW, that's also what you do to pull a web app locally with an iPhone (+ then "Add to Home Screen").
Issue is that there is no visible indication that a webapp can be used locally (as far as I've seen anyway). A nice demo has been glyphboard (http://mrgan.com/gb/) which, when locally installed, provides an app with various "rare" unicode characters (☃, ♪ or ☮ for instance) which you can copy/paste into some other application, but when getting on the original page, nothing in the phone's UI itself tells you there is a local component, the site itself has to point it out.
Another thing I'm not too sure about is the updating: according to the dive page, when the browser encounters a manifest of an (locally) existing application, it checks if that manifest is younger than the one it already has. But if what we're opening is the local applications, does it try to check the remote manifest or not? It does seem that the local Glyphboard accesses the original website when I open it (or tries to anyway) according to the iPhone Simulator, but is it how it's supposed to do?
These are all technical points that, while perfectly legit, are smaller than the problem at hand.
It doesn't really matter if you know its "online" or "offline", because thats as easy as a status indicator. It doesn't really matter what the manifest logic is from this high of a level - that can be ironed out.
It would be my intuition to say its more important to get a prototype working (ala WebOS/iPhone) for insta-downloaded-web-apps and see what the actual problems are technically, and for the users, before speculating what could slow us down before we even begin.
I don't think the UI issue of knowing whether a web application can be locally installed is a small oner no. It is in fact a huge one, especially in the light of most users not being aware this concept is even possible. It's also not very technical at all.
And the issue of update is also an important one, users have been taught that new versions just happen without having to do anything, it's vital that local web applications behave correctly for that as well.
> It doesn't really matter if you know its "online" or "offline"
I don't think I said anything about on/off line, did I?
> It would be my intuition to say its more important to get a prototype working
What prototypes? Local web applications work right now on all three modern, webkit-based mobile platforms. The problem is very much the first one I pointed out, namely how does the user know that he can install a web application.
Rack::Offline for Ruby, and optionally Rails, (written by Yehuda Katz) looks like it does that, though I haven't actually used it: http://github.com/wycats/rack-offline
I've been playing around with html5 local storage, and it's kind of cool for speeding up some operations by caching data that is frequently used, but like any caching, expiration is still potentially tricky.
Also, the really hard and awesome part for me is syncing/merging online-offline - a standard(s) solution for that would be a real killer app enabler. (Because we all are not online 100% of the time, even if only due to spotty reception or on planes, and it sucks not to be able to access your data).
"Downloading an app" is simply going to the web page when you are online initially, and then adding a (possibly automatically) shortcut to the "desktop."