Re: TAG Comment on
Thank you. Please let me know if there are any significant changes to the status of this. Noah Chair: W3C Technical Architecture Group On 11/30/2011 12:57 PM, Arthur Barstow wrote: Noah - FYI, I updated [Action-640] to include the TAG's comment [LC-2] (it originally was only for Ashok's personal comment [Ashok]) and updated LC-2 to connect it to Action-640. -AB [Action-640] http://www.w3.org/2008/webapps/track/actions/640 [LC-2] http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 [Ashok] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0837.html On 11/18/11 10:44 AM, ext Noah Mendelsohn wrote: Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 Thank you. Noah On 11/18/2011 10:01 AM, Arthur Barstow wrote: Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 If anyone wants to propose extensions or changes to Web Storage, please use [Bugzilla] and please feel free to contribute to the group's [Database] wiki e.g. to clarify the relationship between Web Storage and HTML5's AppCache. If you have any additional feedback, please reply by November 25, the day the CfC to publish a Candidate Recommendation of Web Storage ends [CfC]. -Art Barstow [Bugzilla] http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG [Database] http://www.w3.org/2008/webapps/wiki/Database [CfC] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html On 11/15/11 5:05 PM, ext Noah Mendelsohn 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/
Re: Call for Contributors: TAG's Web App Storage work [Was: Re: TAG Comment on Web Storage]
I should also clarify that the TAG itself has not at this point reached consensus on the goals or scope for any work we might do in the storage area, though we have given Ashok an action to investigate what, if anything, might be useful. One possible direction would be for the TAG to do what it has done in some other areas, which is to clarify architectural principles relating to client-side storage in general. E.g., the TAG might discuss tradeoffs and good practice relating to cases in which the information stored locally is also a representation of a resource available on the network (thing of an architecture in which e-mails can be accessed via URI from an online Web server, or can be stored locally for offline access.) Such consideration by the TAG might well not suggest any changes to plans for APIs, but might just suggest good practice for use by applications. Conversely, the TAG might decide to become involved in other questions, such as those that might follow from our recent last call comment [1] regarding the relationship between appcache and Web Storage. In any case, except for the decision to make that one last-call comment, the TAG has not reached consensus as to what work we might do relating to client-side storage. Noah Mendelsohn TAG co-chair [1] http://lists.w3.org/Archives/Public/www-tag/2011Nov/0070.html On 11/23/2011 6:09 PM, ashok malhotra wrote: 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
Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 Thank you. Noah On 11/18/2011 10:01 AM, Arthur Barstow wrote: Noah - the TAG's comment has been added to the comment tracking document for this LC: http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 If anyone wants to propose extensions or changes to Web Storage, please use [Bugzilla] and please feel free to contribute to the group's [Database] wiki e.g. to clarify the relationship between Web Storage and HTML5's AppCache. If you have any additional feedback, please reply by November 25, the day the CfC to publish a Candidate Recommendation of Web Storage ends [CfC]. -Art Barstow [Bugzilla] http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG [Database] http://www.w3.org/2008/webapps/wiki/Database [CfC] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html On 11/15/11 5:05 PM, ext Noah Mendelsohn 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/
TAG Comment on
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/
TAG Comment on Web Storage
Sorry I messed up the subject of the first copy of this note. (I was checking to make sure I got the title of the working draft right, put it in the body of the note, and forgot the subject line). Please accept my apologies...the risks of working in a hurry while running out the door. Noah On 11/15/2011 5:05 PM, Noah Mendelsohn 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/
Re: TAG Comment on
Speaking for myself now, and not necessarily for the TAG: I agree with those who say or imply that it's late for making incompatible changes to the Web Storage specification. I'm less clear that's the case for appcache, given comments about its many problems at the workshop last week, but just for purposes of this email let's assume that it too might be too widely deployed to change wholesale. I also think the TAG is right to ask that the relationship between the two be considered more carefully than, as far as I know it has been. There are many dimensions in which one could imagine innovating to improve the synergies without necessarily disrupting existing deployments. To pick one example signaled in the TAG's email, I would think that one could innovate with application management (e.g. install/uninstall) and space management (query space used by application, set quotas, etc.) that could be done in ways that are compatible with the existing specs. Maybe or maybe not it would be beneficial to integrate them further, e.g. by providing a standard means for storing app-cached resources in Web Storage or otherwise integrating what are now disparate clumps of application data. Whether these will prove to be good things to do is TBD, but I agree with the rest of the TAG that doing the work to find out is important. I also think there are many potentially useful changes that could be made without inappropriate disruption to early deployments. FWIW: I would rather not debate here the difficult balance, in general, between deploying early enough to get real user feedback before specs are frozen, and then finding that you can't actually change the specs based on that experience, because deployment is too widespread. That's a very important debate, but for this thread, I would rather just concentrate on seeing what's practical and beneficial with respect to application storage in particular. I think there are still some things worth looking at. Noah On 11/15/2011 9:41 PM, Bjoern Hoehrmann wrote: * Tab Atkins Jr. wrote: On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adamsgl...@skynav.com wrote: Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. Use of a feature does, in fact, imply that, unless there are *very* good reasons why not. Specs and implementations advance together, and both constrain the other. Well, they advance from Working Draft to Working Draft and then it's too late to make changes before there is a Call for Implementations as the implementations have already been shipping for years. The Last Call is meant to avoid that, providing an opportunity to build a consensus even with people and organizations that cannot follow the day-to-day working group and implementation progress to prioritize their reviews. Which the Last Calls relevant to this thread obviously do not provide.
