Re: Making offline apps easier?

> Making offline apps easier?

Feels like we're still at the 'make it possible' phase more so than the
'make it easier' phase.

I think it's fitting that appcache and widgets were listed at opposite ends
in your list because  the intent of the former is to make it possible for
"drive-by-web" sites to function without a network, while the intent of the
latter is to provide an html+css+js packaging format to facilitate
distribution and deployment out-of-band of the traditional drive-by-web
experience. At least imho.

There are a number of vendor specific packaging formats being heatedly
worked on as well as the ecosystems to distribute and deploy them. In part
at least, the rapid rate of change in the packaged app world(s) is possible
due to the lack of standards. Different ecosystems  are coming into being
independent of one another. Imposing a standards process would probably
slow their progress which probably explains the lack of interest in vendors
on the "official" widget stack.

In contrast, there is less progress being made in direct support of the
"drive-by-web" case. There is the "fixit" group which is groping around the
the area. And some recent spec changes that might help, but I think vendors
are somewhat hesitant to make changes for a handful of reasons (in no
particular order):
* conflicts of interest with their vendor specific packaged apps formats
* FUD about fragmenting the web
* hazy vision on how to build upon appcache or some replacement

Given that view of the world, I'd vote for the public-webapps group to
focus on the "drive-by-web" case, because to step into the packaged app
world could hurt current developments more than it helps. And as with most
things that are developed for the "drive-by-web" case, the packaged app
worlds could pick them up more or less for free (by virtue of constructs
like the embedded <browser src="http://something/on/the/drive-by-web"> tag).

Explicit storage apis like IndexedDB, Filesystem, and LocalStorage are very
necessary for "offline". Development of two of those three are humming
along nicely in a critical mass of browsers. The real laggard is the
appcache. We need a good way to bootstrap apps while offline. That can be
accomplished to a degree but it's clunky and comes with some odd
constraints and baggage.

Imo, a critically missing piece of the puzzle is how to accommodate deep
url  navigation w/o a network.  Cold start the browser, navigate via
bookmark or a history enabled auto-complete to a  url buried deep in the
"app".  We have no good story for that.  The ability to store and retrieve
data on the local system is covered already. Some amount of HTTP resource
caching is done already. But very little is done that allows intelligent
use of those stashes of locally stored data *before* a document is loaded
into a frame.

Another missing piece of the puzzle is providing better control over the
set of HTTP resources that are cached. The flat list of urls in the
manifest file is too constraining. Some means of grouping subsets
of resources for addition, update, and removal.

The automagic addition of "master" entries is too often an unwelcome,
annoying, surprising addition.  Just got another bug report about that
today.

Most difficult is finding a way to craft things such that the "online"  vs
"offline" experiences aren't completely different from both the end user
and developer point of view.

I think the best way to get to a satisfying answer for the critically
missing piece  is by allowing scripts to satisfy resource requests,
computing/composing a response from locally stored data, or designating the
return of a cached HTTP response, or trying to make a network request first
then taking local action. I'm less sure that hanging that capability off of
the appcache is the best way to go, but it seems like an option. Or that
capability could be a specified as separate piece. I also think a
capability like this would give app developers the tool they really need to
blur the distinction between 'online' vs 'offline' in ways that make sense
for their apps.

If public-webapps wants to help make offline easier, the appcache feature
set is the area that needs the most help.

Cheers
Michael



On Mon, Nov 12, 2012 at 8:11 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> Hi folks
>
> We have a handful of things that could be on our plate here.
>
> 1. Appcache.
> Yeah, we know. But if nobody makes a proposal, nothing will get better.
> (There is also a "fixing-appcache" community group taht might come here
> with proposals).
> 2. Offline apps breakout at TPAC
> http://www.w3.org/wiki/**TPAC2012/Offline_Apps<http://www.w3.org/wiki/TPAC2012/Offline_Apps>Ashok Malhotra (Oracle, who
> aren't webapps members), ran a session. Where we agreed to divide the
> thoughts into "the app shell" and "the app data" - either of which could
> be brought from offline, or online, independently. Plus I made a half-page
> note about different ways of having apps offline
> 3. File APIs.
> The plain File reader seems almost done. Still. There are apparently
> people interested in a File System (Opera implemented one for Opera Unite,
> Chrome and Yandex have one, and there are discussions about making a
> simpler one).
> 4. Databases
> IndexedDB seems to be getting traction across all platforms. Unlike at the
> face to face, when literally nobody spoke in favour of WebSQL, there are
> people who think it is worthwhile. At the same time Ashok has been hinting
> at using something more seriously SQL to help with issues like synch
> (which always seems like it won't be that hard, but never actually works
> entirely properly after all).
> 5. Widgets and packaged apps
> There is the "official" widget stack. At the face to face the only people
> who spoke up in favour of keeping this alive and connected to other app
> systems were Zynga. There is the Mozilla proposal for apps packaged with a
> JSON manifest, and Yandex has the same functionality but probably slightly
> different syntax for the JS. And there may be others...
>
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>         chaals@yandex-team.ru         Find more at http://yandex.com
>
>