Any plans on tying into HTML5 app cache manifests (and other features)?

[Brett C.]

After reading the developer's guide there is an obvious overlap with
stuff being specified in HTML5:

+ app cache manifests (http://www.w3.org/TR/html5/offline.html#concept-
appcache-manifest)
+ link rel="icon" (http://www.w3.org/TR/html5/interactive-
elements.html#rel-icon)
+ specified prompting of abilities to use abilities, e.g. asking if
it's okay to use geolocation

So short of the FALLBACK section of an app cache manifest, the web app
manifest being proposed doesn't add anything that can't be done in
HTML5 already (or is being proposed).

But that's fine! I am sure you guys have plans beyond what HTML5 can
offer and are not ready to discuss yet. But what I'm wondering about
is whether you plan to make it easy to tie the HTML5 way of doing a
web app in with the way you are proposing to handle it. I mean I can
easily see a tool that takes the URL of a web app and generates the
beginnings of a web app manifest for Chrome. And the same can be said
in the other direction.

I just see a slight pain in deployment in having to support the two
ways of producing a web app without some tool support to go from one
to the other. This will be especially true if I have to upload a
new .crx file every time I update the web app store (which I will
obviously want to do in order to get wide spread deployment) when with
the HTML5 app cache I simply update the files on my web server and a
new version is then instantly deployed when the app reloads in their
browser.

Which reminds me, what do you plan to do about web apps that are
server-based -- do not contain all files in the .crx file -- but that
do provide an HTML5 app cache manifest? Will you serve those cached
files? Or will you only serve the files from the .crx file? At that
point, short of the mainfest.json file and the icons being available
for showing on the app store, could a HTML5 app cache manifest with
all files needed by the web app make it the equivalent of a serverless
web app?

[Aaron Boodman]

Hi Brett,

On Wed, May 19, 2010 at 5:06 PM, Brett C. <bca...@gmail.com> wrote:
> After reading the developer's guide there is an obvious overlap with
> stuff being specified in HTML5:
>
> + app cache manifests (http://www.w3.org/TR/html5/offline.html#concept-
> appcache-manifest)

The app cache manifest is really a separate feature from the
installable web apps we're adding to Chrome. We're looking into
whether it is possible to combine them, but don't yet know if that
will work.

> + link rel="icon" (http://www.w3.org/TR/html5/interactive-
> elements.html#rel-icon)

These icons are page specific. We really need an icon that represents
the entire app, not a single page. When you install an app, we need to
know at that moment which icon to use to represent it. Also, it is
possible for developers to change the value of <link rel="icon"> at
runtime, and browsers actually change the rendering. This makes them
great for showing status, but inappropriate for representing an app.
You wouldn't want Gmail's permanent icon in your launcher to show that
you have unread messages, for example.

> + specified prompting of abilities to use abilities, e.g. asking if
> it's okay to use geolocation

HTML5 doesn't yet provide for a way for authors to declare that an
application requires multiple permissions. Like say, notifications and
geolocation.

> So short of the FALLBACK section of an app cache manifest, the web app
> manifest being proposed doesn't add anything that can't be done in
> HTML5 already (or is being proposed).

This isn't true. The differences are:

- Ability to declare the set of URLs that constitute an app,
independent of declaring any caching behavior for them.
- Ability to declare a set of icons that represent the app.
- Ability to declare that a set of HTML5 permissions should be
accessible to the app w/o prompts.

HTML5 app cache manifests and installable apps are actually completely
orthogonal.

> But what I'm wondering about
> is whether you plan to make it easy to tie the HTML5 way of doing a
> web app in with the way you are proposing to handle it. I mean I can
> easily see a tool that takes the URL of a web app and generates the
> beginnings of a web app manifest for Chrome. And the same can be said
> in the other direction.
>
> I just see a slight pain in deployment in having to support the two
> ways of producing a web app without some tool support to go from one
> to the other. This will be especially true if I have to upload a
> new .crx file every time I update the web app store (which I will
> obviously want to do in order to get wide spread deployment) when with
> the HTML5 app cache I simply update the files on my web server and a
> new version is then instantly deployed when the app reloads in their
> browser.

Combining the two features is something we're looking into. In the
meantime, I do not think that developers will need to update their CRX
files very often. You only would need to do that when the metadata
about an app changes (its permissions, its icons, or its URL
structure).

> Which reminds me, what do you plan to do about web apps that are
> server-based -- do not contain all files in the .crx file -- but that
> do provide an HTML5 app cache manifest? Will you serve those cached
> files? Or will you only serve the files from the .crx file? At that
> point, short of the mainfest.json file and the icons being available
> for showing on the app store, could a HTML5 app cache manifest with
> all files needed by the web app make it the equivalent of a serverless
> web app?

This will work fine. Developers can use app caches and installable
apps together, or use either one of them separately. If app cache
works better for your application, that's great.

- a

[Brett Cannon]

On Wed, May 19, 2010 at 17:25, Aaron Boodman <a...@google.com> wrote:
> Hi Brett,
>
> On Wed, May 19, 2010 at 5:06 PM, Brett C. <bca...@gmail.com> wrote:
>> After reading the developer's guide there is an obvious overlap with
>> stuff being specified in HTML5:
>>
>> + app cache manifests (http://www.w3.org/TR/html5/offline.html#concept-
>> appcache-manifest)
>
> The app cache manifest is really a separate feature from the
> installable web apps we're adding to Chrome. We're looking into
> whether it is possible to combine them, but don't yet know if that
> will work.

True. My bias is showing through as the web app I am thinking about in
the back of my head for this is completely serverless, so that's where
my head is.

>
>> + link rel="icon" (http://www.w3.org/TR/html5/interactive-
>> elements.html#rel-icon)
>
> These icons are page specific. We really need an icon that represents
> the entire app, not a single page. When you install an app, we need to
> know at that moment which icon to use to represent it. Also, it is
> possible for developers to change the value of <link rel="icon"> at
> runtime, and browsers actually change the rendering. This makes them
> great for showing status, but inappropriate for representing an app.
> You wouldn't want Gmail's permanent icon in your launcher to show that
> you have unread messages, for example.
>

Very good point. I guess theoretically you could say that the web app
icon will be based off what you would have put in the "launch" value
in the manifest.json, but obviously a clear specification has its
perks.

>> + specified prompting of abilities to use abilities, e.g. asking if
>> it's okay to use geolocation
>
> HTML5 doesn't yet provide for a way for authors to declare that an
> application requires multiple permissions. Like say, notifications and
> geolocation.

Right. I'm not advocating that the HTML5 is superior to how you are
suggesting to do, and I apologize if that's how I came off. It's just
an alternative approach to ask lazily instead of eagerly.

Unless it's serverless, which is what I'm personally interested in.
That's the pain point I'm truly interested in.

>
>> Which reminds me, what do you plan to do about web apps that are
>> server-based -- do not contain all files in the .crx file -- but that
>> do provide an HTML5 app cache manifest? Will you serve those cached
>> files? Or will you only serve the files from the .crx file? At that
>> point, short of the mainfest.json file and the icons being available
>> for showing on the app store, could a HTML5 app cache manifest with
>> all files needed by the web app make it the equivalent of a serverless
>> web app?
>
> This will work fine. Developers can use app caches and installable
> apps together, or use either one of them separately. If app cache
> works better for your application, that's great.

Personally I would rather do it the way you are planning it (from a
security perspective having the code easily available to audit along
with the checksumming is nice). =) But if the other browser
implementors don't pick it up then I am going to feel compelled to
support the HTML5 way of doing a serverless apps to support the
largest number of users. Here is to hoping your work catches on enough
that it begins to supersede HTML5's approach for doing serverless
apps. But I do appreciate you all supporting the HTML5 tie-in through
the app cache manifest.

And thanks for the quick reply, Aaron.