Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)

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 :)  

Well, you are on the program committee of an upcoming workshop that
lumps them together:
        As mentioned above, the World Wide Web Consortium has already
        developed standards to facilitate the development of off-line
        Web applications:
            the HTML 5 Working Group's Application Cache;
            the Web Applications Working Group's Packaging and XML
        Configuration.
http://www.w3.org/2011/web-apps-ws/

> > 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.

> > > 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.

> > 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.

> > > IMO, keeping them together will lead to confusion. The use cases are
> > > different: a widget can embed content that uses ApplicationCache, as
> > > well as load in proprietary APIs (e.g., WAC).
> >  
> > Surely a Web-applicationcached app could also load proprietary APIs.
>
> How? What mechanism does a proprietary unpacked web application have to do this? And do you have any actual real examples of this happening in the wild?  

ActiveX and other plugins seem to have provided this for quite some
time? Not to mention vendor-prefixed APIs?

> >  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.

> > >  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.

>  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 don't think that lumping them together means they are the same
technology covering exactly the same use cases, otherwise my document
would also assert that SVG, canvas and CSS are the same.

> > 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.

> > etc), but I still don't see how they would fundamentally address
> > different use cases.
>
> If you don't understand widgets, then please read the specification,

As you probably know, I've read the widget specs quite a few times.

>  or take the Editor's word for it (I've been at this for 5 years, so I
> think I know what I am talking about when it comes to widgets)

That's argument by authority, so hardly an argument :)

Dom

Received on Friday, 16 September 2011 15:00:57 UTC