On 9/16/11 8:00 AM, Dominique Hazael-Massieux wrote:
Le vendredi 16 septembre 2011 à 21:36 +0700, Marcos Caceres a écrit :
I think they are actually not so different, and share many use cases.
Ok, I strongly object in the strongest of terms to them being put together and
I'm more than happy to debate any argument you might have for lumping them
together. Here we go :)
http://www.w3.org/2011/web-apps-ws/
Dominique is not the only one to be wondering about the distinction.
I've been watching Google implement their .crx packaging mechanism over
the past year and a half:
in that time, they've not reconciled the two distribution strategies any
further.
Hosted apps, still, are what we are looking at for distribution. A
hosted app consists of a very
simple permissions manifest (title, author, url, permissions requested)
and for efficiency and offline use, a website that implements
applicationCache.
Google has also, for some time, carried a development flag "CRX-less Web
Apps - Enables support for installing Chrome apps that are deployed
using a manifest file on a webpage, rather than by packaging the
manifest and icons into a crx file.".
This brings packaging even closer to the applicationCache model.
As a developer, I'd like to see a little bit of both: I'd like to be
able to ship all of my content in a Widget, to save myself the use of
bandwidth, but allow the application to be updated via applicationCache
mechanisms.
ApplicationCache can be used to group a bunch of HTML, CSS and JS files
that constitue an "installable application" (e.g. the way the iOS safari
browser let you save to your homescreen an offline Web app when an
application cache is present).
I'm sorry, but that has absolutely nothing to do with Application cache. It's
done like this:
<link rel="apple-touch-icon" href="/icon.png">
Sure, that bits helps for having an icon on the homescreen; it's fair to
say that rel="apple-touch-icon" (and its standard equivalent rel="icon"
with the sizes attribute) completes ApplicationCache in matching the
features that widget packaging provides.
But without the application cache, your nice and shiny icon won't load
anything if you're not connected;<link rel="apple-touch-icon"> is the
equivalent to<icon> in config.xml, where ApplicationCache is the list
of files encoded in the Zip file.
It's also quite similar to favicon.
Favicon sure has had a long run. It's becoming even more widely used, with
browser home screens turning into application-launcher screens.
There are so many ways we need to package icons now. Google and Apple
platforms
ask for a whole collection of them in different sizes.
I tell you, as absurd as it may be, a css media type of "icon" is
closing in on us.
ApplicationCache is cache control thing: it does not "package" a Web
Application; just makes some resources available from the cache
(potentially for off-line use). The end user has not control over it
and the author can shut it off at any point.
The end user *could* have control over it if the user agent let her (the
But the user agent doesn't let her, because he is mean. And I don't
think that is the way the spec was written (though I need to check).
But I doubt the spec says anything about that, as it seems the author
is king in that situation.
I agree that the widget specs say a lot more on application management
than ApplicationCache (which more or less only deals with updates and
connectivity); but the applicationcache spec certainly doesn't forbid
user agents to do smart things with it, as the iPhone implementation
shows.
As far as I know, (at least) Mozilla is working on "saving as Web
application", and I would be extremely surprised if they didn't use the
applicationcache when available to do that.
I expect the same. When/if a user decides that a web application is
-important- to them, they do grant it additional permissions, such as
increasing file storage limits (or perhaps, duration of the temporary
file system). That method seems to be working, and preferred, for most
use cases.
I know that one of our apps asks for "access to everything you have ever
done" -- It could be more granular, if mechanisms were in place...
Asking for things like CORS exceptions.
Whether packaged as a widget, or distributed via applicationCache, there
is the question of automatic updating, and how to handle all of that.
I'm certainly more pleased with Google Chrome's automatic updating
feature than I am with the bi-weekly (I kid) updates pushed out by
Oracle for Java, interrupting my day to remind me that Java is installed
on my OS.
I think "updating" ought to be looked at from a permissions perspective.
As a user, I'd like to be able to say: keep this app cache, no matter
what. That'd let me lock-down some systems from man in the middle
attacks, once the app is installed. Considering recent SSL breaches,
it's a reasonable use case.
same way a widget user agent could also automatically remove widgets
that their authors wish to retract).
There is no provision in any of the specs to do this. Certainly not by design,
unlike HTML5.
Right; but knowing how application stores tend to have a remove-this-app
switch, I'd be surprised if many applications stores based on widgets
didn't have a similar ability.
It looks like this is all about permissions. implicit, explicit and managed.
And
an application cache could also have a widget as part of its list of
cacheable resources.
Sure, they could have bananas too and all sorts of hypothetical things too. But
they don't.
Right, because that's not terribly useful. But you brought the fact that
one technology could embed the other, I didn't.
I'd like this. Something like a new field type in application cache
documenting a widget by cryptographic hash, and documenting
which files in the application cache are not necessary, if that widget
is installed.
It'd be just as useful for shared libraries as it would for mixing packaged
and unpackaged widgets.
It can be used for defining other classes of applications and formats
(e.g., Opera Extensions).
I can also imagine using ApplicationCache to do that.
You have a wild imagination :) I'm sure there is a good reason why no
one has done it.
In any case, the document is discussing concrete things, not
imaginary things.
Right; the document is not discussing the fact that widgets can also be
used for creating browser extensions, or providing server-side lump of
content. It's discussing packaging web applications for offline usage.
From watching Google, I can see that they are trying to take extra
precautions on hosted vs. packaged widgets. Hosted are very much like
applicationCache, with a sprinkling of permissions.
There are some high-security items where they only allow packaged apps
to access sensitive APIs. But even some of those are gradually being
pushed into the hosted apps realm. Web Intents is a good example. On
Chrome OS, the user can install a widget which can register itself as a
file handler, by file type. They only allow this for packaged
applications. But, Web Intents is working on this use case, and will
extend that functionality to hosted applications.
Please base the document on real world things, not on things you
imagine.
I don't think I'm imagining that both widgets and applicationcache
provide a way to package Web applications for users. At least, you still
haven't convinced me that they don't.
I hope my real world examples are a help, here.
Widgets and ApplicationCache differ in some ways (e.g. the security
model of widgets is different, widgets currently don't have an origin,
The do have an origin! It's called widget:// and it's an completely
conforming origin: Please look up the definition of origin in the
HTML5 spec.
Indeed, my mistake.
Well you know, on the web today, it's typically called chrome:// and
chrome-extension://.
It's an easy mistake to make.
-Charles
