W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Fri, 16 Sep 2011 21:36:20 +0700
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: public-webapps@w3.org
Message-ID: <AA589C9DF5864C2D9F35191CD9AE60AC@gmail.com>
Hi Dom,  

On Friday, 16 September 2011 at 19:55, Dominique Hazael-Massieux wrote:  
> Hi Marcos,
> Le samedi 03 septembre 2011 à 22:47 +0200, Marcos Caceres a écrit :
> [sorry for the delay in responding]
> > Thank you for continuing to keep the document up to date. This document is very helpful.  
> Thanks!
> > I have request: can you please ungroup Widgets and HTML's
> > ApplicationCache? They are conceptually different things and have
> > different use cases.
> 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 :)  
> > Widgets are a way to zip up a bunch of HTML, CSS, and JS files that
> > constitute an "installable application" (or some such). That is,
> > something someone might want to distribute to keep.  
> 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">
It's consequential that a web application is using app cache.  
> > 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.  

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

>  I don't think there is anything
> fundamental is the underlying technologies that prevent or facilitate
> that particular use case.
It's clearly evil to do this (specially in the widget case, implying you do it with updates). Imagine if Microsoft decided one day to trash every user's copy of Windows through an update. Yeah, it's possible, but it just would not happen…. on the other hand, it seems to the norm with AppCache (as things are updated… though I have been in situations where I was locked out of an app, much to my annoyance).  
> > 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?  
>  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.  
> >  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. Please base the document on real world things, not on things you imagine.  

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

> 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, 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) or please remove them from the document.  

Kind regards,
Received on Friday, 16 September 2011 14:36:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:34 UTC