- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 15 Nov 2011 16:00:05 -0800
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Chromium devs put forward a unified quota API recently. localStorage provides 5 megs of UTF16 storage; or about 2 megs of storage for binary files saved as base64 strings. It's terrible for that use. appCache had some Apis in existing proposals for programatically adding items. I don't know if vendors have been interested in implementing them. https://developer.mozilla.org/en/nsIDOMOfflineResourceList I've certainly wanted a simple key-val blob store. We still don't have one. Even a means to persist Blob Uris would be an improvement. On Nov 15, 2011, at 2:05 PM, Noah Mendelsohn <nrm@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/ >
Received on Wednesday, 16 November 2011 00:00:41 UTC