Making offline apps easier?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Making offline apps easier?

Chaals McCathie Nevile
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 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
         [hidden email]         Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

RE: Making offline apps easier?

arnaud.braud
Hello,
Some comments inline,

> -----Message d'origine-----
> De : Charles McCathie Nevile [mailto:[hidden email]]
> Envoyé : lundi 12 novembre 2012 17:11
> À : public-webapps WG
> Objet : Making offline apps easier?
>
> 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 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...


I'd also add a
6) Zip Archive : which was discussed at last TPAC.

It might be worth trying to flatten our use cases and see where we have huge gaps and avoid running too many specs for one given use case.


>
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>          [hidden email]         Find more at http://yandex.com


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: Making offline apps easier?

Ian Hickson
In reply to this post by Chaals McCathie Nevile
On Mon, 12 Nov 2012, Charles McCathie Nevile wrote:
>
> 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).

There are already several proposals, and they are already making their way
through to the spec. If anyone has any use cases that they haven't filed
as bugs on the WHATWG spec or e-mailed the WHATWG list, please don't
hesitate to do so, so that they can be considered. It's use cases that are
needed, not proposals, to make additional progress here beyond what will
happen already given the currently-filed bugs.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: Making offline apps easier?

Todd Blanchard-2
In reply to this post by Chaals McCathie Nevile
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).
I do this a lot in a couple apps and have a nice little framework that goes from json to sqlite and back.  Basically we project a hunk of our database schema into the app populated with data relevant to the user and we keep that little chunk of the world sync'd via timestamps.
Reply | Threaded
Open this post in threaded view
|

Re: Making offline apps easier?

Michael Nordman
In reply to this post by Chaals McCathie Nevile
> 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 <[hidden email]> 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 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
        [hidden email]         Find more at http://yandex.com