Re: Widgets & ApplicationCache

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

Received on Friday, 16 September 2011 16:31:33 UTC