Re: Call for Contributors: TAG's Web App Storage work [Was: Re: TAG Comment on Web Storage]
Hi Mark: The idea is to involve some of those folks in this effort. All the best, Ashok On 11/23/2011 2:49 PM, Mark Nottingham wrote: What effect will this effort have on the implementations? Are they listening? Cheers, On 23/11/2011, at 11:49 PM, Arthur Barstow wrote: Hi All, Off-list, Ashok and I talked about his comments and TAG's Web Application Storage work [1]. Ashok would welcome WebApps' participation in that work. Thus, for the WebApps group - this is call for contributors. If you are interested in contributing to this area, please respond to this e-mail (off-list responses are fine too). -Art Barstow [1] http://www.w3.org/2001/tag/2011/sum10#webappstorage On 11/21/11 2:14 PM, ext Arthur Barstow wrote: On 11/20/11 8:33 PM, ext ashok malhotra wrote: The idea is not to remove APIs. We have several client-side storage facilities that cover different but overlapping usecases. Can we step back and look at what we have and come up, perhaps, with a smaller set of facilities and better coordinated APIs. If this is important to the TAG, it seems like you should add that task to the Web Application Storage work the TAG intends to do. Agreed? -AB [1] http://www.w3.org/2001/tag/2011/sum10#webappstorage -- Mark Nottingham http://www.mnot.net/
Re: TAG Comment on
The idea is not to remove APIs. We have several client-side storage facilities that cover different but overlapping usecases. Can we step back and look at what we have and come up, perhaps, with a smaller set of facilities and better coordinated APIs. All the best, Ashok On 11/20/2011 3:42 PM, Adam Barth wrote: On Sun, Nov 20, 2011 at 3:30 PM, Mark Nottinghamm...@mnot.net wrote: Yes, if you configure your browser to do so, you'll be assaulted with requests for a test db from many Web sites that use common frameworks. I don't think that this should count as use. Indeed. That is not the sort of use I'm referring to. I do think now is precisely the time to be asking this kind of question; these features are NOT yet used at *Web* scale -- they're used by people willing to live on the bleeding edge, and therefore willing to accept risk of change. You're welcome to tilt at that windmill, but the chance that you get these APIs removed from browser is approximately zero. Adam One of the problems with lumping in a lot of new feature development with a spec maintenance / interop effort is confusion like this. Hopefully, the W3C (and others) will learn from this. On 16/11/2011, at 9:47 AM, Adam Barth wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohnn...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/ -- Mark Nottingham http://www.mnot.net/
Re: TAG Comment on
But we should give it a try, no? The spec are still Working Drafts. All the best, Ashok On 11/15/2011 2:47 PM, Adam Barth wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohnn...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Last Call Comments on Web Storage
DISCLAIMER: The opinions expressed below are mine and may not reflect the opinions of my employer or the W3C TAG Comments: o One use of local storage might be to store personal preferences, such as travel preferences or personal information such as medical history. In such cases, you may want to allow several sites access to this information (I prefer aisle seats; I would like to stay at Marriott hotels.) Local storage is governed by the same-origin policy but in some cases it may be wise to carefully relax this and allow multiple sites to access the data. o When updating local storage, transactional semantics or, at least, a transactional option would be desirable. o It would be very useful to be able to map from other forms of data storage, such as RDF or Relational data to RDF. Mapping from RDF would be simple. Mapping from Relational is more challenging. o If local storage is used to store personal preferences or personal information it would be very useful to be able to move it from one device to another, say my laptop to my phone. The last two comments involve tools built around the spec and not the spec itself. Other tools that would make local storage more useful and more convenient can be envisaged. o Question: The values in the key-value pairs are typed as strings but I presume they can be URIs and be interpreted as URIs. Or they can be large files. Perhaps this could be clarified.
ACTION-438 Question about possibility of cross-site data sharing in Web Storage
At the TAG f2f meeting last week we discussed the Web Storage (http://dev.w3.org/html5/webstorage/) draft. As you know, Web Storage provides storage mechanisms (local storage and session storage) by origin. This led us to conclude that it supports the same-origin policy. But section 6.1 contains the sentence “User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas.” This prompted some of us to speculate that a door is being left open for cross-site information sharing in the manner of CORS (http://www.w3.org/TR/access-control/)or UMP(http://www.w3.org/TR/UMP/). Would you agree that this reading between the lines is justified?
Re: ACTION-401Ask WebApps to Review Taxonomy
Thanks, Marcos! We will discuss this at the TAG mtg next week. All the best, Ashok Marcos Caceres wrote: (The following is my personal opinion about widgets) On Thu, Mar 11, 2010 at 10:58 PM, ashok malhotra ashok.malho...@oracle.com wrote: John Kemp has kindly created A Taxonomy of Web Applications for the TAG. See http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy/web-apps-taxonomy.html It would be good if some of the WebApps folks could review and comment. Also, I suspect that behind the many documents that the Web Apps WG is producing lies an architectural vision. If someone could spend a few minutes articulating this vision, I think it would be very helpful. I had a quick look, and just wanted to raise two points... # Trust often established between widget and widget platform (by means of crypto signatures) This is not quite right: The Dig Sig spec says Widget authors and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and to confirm the signing key(s). However, this should not be confused with trust in any way (e.g., an author I trust could turn evil, or the widget could be hijacked). # Trust often proxied by use of an app-store model Again, I kinda get what you mean here, but this is not the sole intention - and an appstore cannot really guarantee trust (as above). There are lots of trust models that will hopefully emerge around widgets (such as community mediated trust - where a community needs to approve something as safe before it can be used on devices). Depending on single points of trust is a bad thing, IMO. The central idea is that anyone can be an app store and that (hopefully) widgets engines will be able to get widgets from anywhere on the Web (i.e., totally decentralized distribution model).
ACTION-401Ask WebApps to Review Taxonomy
John Kemp has kindly created A Taxonomy of Web Applications for the TAG. See http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy/web-apps-taxonomy.html It would be good if some of the WebApps folks could review and comment. Also, I suspect that behind the many documents that the Web Apps WG is producing lies an architectural vision. If someone could spend a few minutes articulating this vision, I think it would be very helpful. -- All the best, Ashok
