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

shortcut: if you want to (incorrectly, IMO) continue to lump widgets and app cache, then do so making it clear that this is just one of the use cases for widgets and certainly NOT the primary use case… And please add a separate section just for Widgets in your document that explains the other cases.  

… now, more bla bla :)  

On Friday, 16 September 2011 at 16:00, 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 :)  
>  
> Well, you are on the program committee of an upcoming workshop that
> lumps them together:
There is nothing at the workshop that lumps them together (certainly nothing of any authority). The point of the workshop is to identify the differences, because, evidently, people are still confused. From the workshop:  

"The current fragmentation in this solution space is creating confusion among would-be WebApp developers and organizations who would otherwise invest in the Open Web Platform." -- http://www.w3.org/2011/web-apps-ws/

I fear that document's like yours, which lump App Cache and Widgets together, don't help the situation (which is why we are having this discussion, which has brought out annoyed Marcos again).  

>  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/
That is consequential. Widgets are a general packaging format and one of its use cases is "off-line web applications". But that is just one. They have been used as server side applications, standalone applications, daemons, and as an extension format.  

I think if you asked Mozilla, or Google, or Apple, or Opera, if their extension formats are "off line web applications" you would get a strange look. If you ask extension developers, I wonder what they would say?  
> > > 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.
I very much doubt the HTML WG looked to copy whatever features Widgets have. It's mere consequence. I also didn't do the reverse. We got to a similar place, but along a different path. And again, AppCache does not match the "features that widget packaging provides". They are apples and oranges. The day I can put an app-cached application on a USB disk, or email it to you, then maybe the above would be a valid statement.  

> But without the application cache, your nice and shiny icon won't load
> anything if you're not connected;
Some apps are not made for offline, not should every web page be built for off-line. It's pretty rare to be offline on an iPhone.  
> <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.
I agree that there are similarities and overlap for this *one* use case; but again, the use cases of Widgets are far greater than ApplicationCache. To lump them together waters Widgets down to a confusing equivalent to AppCache. This is confusing people because then they will think "oh, that's widget thing is just a stupid way of doing app cache' and that is just wrong. No one that I know of is doing both.  

Again, the purpose of widgets is a general packaging format: not "offline web applications" - that is just _one_ of an number of use cases for which widgets have been used for. Until AppCache is extended to do more than it does at the moment, they remain separate things.  

> > > > 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.
I don't know of any "smart" thing the iPhone does? I just did a quick google and could not find anything? Did they add something interesting lately that I missed?  

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

If you mean prism: "A web application bundle (https://wiki.mozilla.org/Prism/Bundle) is a zip archive that holds a configuration (https://wiki.mozilla.org/Prism/Config) file, icons and an optional webapp JS script (https://wiki.mozilla.org/Prism/Scripting)."  

https://wiki.mozilla.org/Prism#Web_Application_Bundles
https://wiki.mozilla.org/Prism/Bundle


Surprise!!! :D  

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

Again, you are theorising and implying things we have explicitly not put into the spec (i.e., no kill switch). That is explicitly baked into HTML5, but not into Widgets.  

> > > > 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?
This is true. But I don't know what the point of comparison is here.  
> > >  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.

Ok.  

> > > >  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.
It's ok for you to do that, so long as you don't lump them together with AppCache and mention the other use cases.  

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

Well, the "packaging" in the case of appcache is conceptual (i.e., you have coerced the meaning of packaging to try to fit into the ideal of packaging - which is clearly doesn't)… In appcache, there is no actual container that packages the content (i.e., you can't pick up an app cache and email it to a friend or keep it on a USB disk, like you can with a .wgt file) . Appcache is not a container format. Widgets are. That's a pretty fundamental, material, and irrefutable, difference.  
> 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.
Right, you are being extremely selective and it's unclear why. Is this a political thing? If it is not, then it certainly feels like it.  
> > > 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.
heh, I knew I could at least get one right:)  

> > > 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.
Then I obviously did a bad job explaining the use cases in the spec as you seem to have ended up thinking about it not as I had intended :(  
> >  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 :)
If it was so meaningless, we wouldn't slap our names on specs. But yes, I'll rely more on hard data, wit, and logic to win you over…. and exotic chocolates or similar bribes, if need be :)

Received on Saturday, 17 September 2011 09:31:18 UTC