Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Le samedi 17 septembre 2011 à 10:30 +0100, Marcos Caceres a écrit : 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… My document focuses on technologies available to build client-side Web applications for mobile devices; the 52 specifications that the document mentions have all use cases that go well beyond that use case, but I don't think the document would win in usefulness or clarity by stating so for each of these specifications. And please add a separate section just for Widgets in your document that explains the other cases. If by the other cases, you mean: They have been used as server side applications, standalone applications, daemons, and as an extension format. Server-side applications, daemons, and browser extensions are clearly out of scope of the document, so I don't think it would make sense to list them. 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. The document specifically says that the two approaches are complementary (not redundant), and summarizes what the two technologies provide. I don't see why having them in the same section would mean they're equivalent (again, no more than having SVG and CSS in the same section would mean they're equivalent). If you think the current description doesn't convey clearly enough the differences between the two approaches, I'll be happy to review a better description (either in reply to this mail, or directly in the wiki http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile ). Dom
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
On Monday, September 19, 2011 at 10:06 AM, Dominique Hazael-Massieux wrote: Le samedi 17 septembre 2011 à 10:30 +0100, Marcos Caceres a écrit : 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… My document focuses on technologies available to build client-side Web applications for mobile devices; the 52 specifications that the document mentions have all use cases that go well beyond that use case, but I don't think the document would win in usefulness or clarity by stating so for each of these specifications. That's fine, but please make that clear - it is not clear enough in the introduction. I.e., just adapt what you say above and put it in the introduction: [[ This document focuses on technologies that may aid in the development of client-side Web applications for mobile devices; the specifications that the document mentions have all use cases that go well beyond the mobile application use case. For example, in addition to aiding in the development of client-side Web applications for mobile devices, W3C Widgets have been used as server side-applications, standalone applications, daemons, and as a Browser extension format. Similarly, [SVG] ... ]] You can fill out the SVG bit or pick some other technology. And please add a separate section just for Widgets in your document that explains the other cases. If by the other cases, you mean: They have been used as server side applications, standalone applications, daemons, and as an extension format. Server-side applications, daemons, and browser extensions are clearly out of scope of the document, so I don't think it would make sense to list them. With a more clear understanding of what you are trying to achieve, I agree. 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. The document specifically says that the two approaches are complementary (not redundant), and summarizes what the two technologies provide. I don't see why having them in the same section would mean they're equivalent (again, no more than having SVG and CSS in the same section would mean they're equivalent). If you think the current description doesn't convey clearly enough the differences between the two approaches, I'll be happy to review a better description (either in reply to this mail, or directly in the wiki http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile ). Dom
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
Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
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. 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). 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 same way a widget user agent could also automatically remove widgets that their authors wish to retract). I don't think there is anything fundamental is the underlying technologies that prevent or facilitate that particular use case. 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. And an application cache could also have a widget as part of its list of cacheable resources. 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. Widgets and ApplicationCache differ in some ways (e.g. the security model of widgets is different, widgets currently don't have an origin, etc), but I still don't see how they would fundamentally address different use cases. Dom
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
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, Marcos
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
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
On 16 Sep 2011, at 13:55, Dominique Hazael-Massieux wrote: 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. And an application cache could also have a widget as part of its list of cacheable resources. 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. I can imagine using all kinds of other things to do that. The point is, I don't want to, I want to use one standard way to do it along with all other companies in the space so we have a market, not a whole bunch of non-interoperating silos, and have a consistent message for users. I don't really understand what the point is of putting these things together. Other than to annoy Marcos of course :) Widgets and ApplicationCache differ in some ways (e.g. the security model of widgets is different, widgets currently don't have an origin, etc), but I still don't see how they would fundamentally address different use cases. Dom
