Re: TAG Comment on
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: 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/
Call for Contributors: TAG's Web App Storage work [Was: Re: TAG Comment on Web Storage]
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
Re: Call for Contributors: TAG's Web App Storage work [Was: Re: TAG Comment on Web Storage]
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: 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: 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
On Mon, 21 Nov 2011 00:47:05 +0100, Mark Nottingham m...@mnot.net wrote: For example, some browsers still (!) support blink, but that doesn't mean we should promote its use. FWIW, blink is defined as a feature in HTML5 browsers are expected to implement. -- Anne van Kesteren http://annevankesteren.nl/
Re: TAG Comment on
On Mon, Nov 21, 2011 at 12:05 PM, Anne van Kesteren ann...@opera.com wrote: On Mon, 21 Nov 2011 00:47:05 +0100, Mark Nottingham m...@mnot.net wrote: For example, some browsers still (!) support blink, but that doesn't mean we should promote its use. FWIW, blink is defined as a feature in HTML5 browsers are expected to implement. Conflating specs with promotion worries me. In particular, it worries me that the specs == promotion mindset might lead to hiding some features from the spec, which would lead back to the bad old days when spec were not even seriously trying to contain the description of what needs to be implemented in order to successfully render the Web. By all means put some kind of Surgeon General's warning about race conditions on localStorage but, please, let's not hide the description of the feature from specs. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: TAG Comment on
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
Re: TAG Comment on
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. 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. 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 Mendelsohn n...@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
On Sun, Nov 20, 2011 at 3:30 PM, Mark Nottingham m...@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 Mendelsohn n...@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
On 21/11/2011, at 10:42 AM, Adam Barth wrote: You're welcome to tilt at that windmill, but the chance that you get these APIs removed from browser is approximately zero. There's a difference between the W3C and browser vendors promoting these as the future of the Web as-is, and supporting them for the (relatively few) people who use them currently, while coming up with something better (i.e., effectively deprecating them). For example, some browsers still (!) support blink, but that doesn't mean we should promote its use. Either way, I'm happy to wait; no windmill-tilting required. -- 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
On Sun, 20 Nov 2011 18:30:15 -0500, Mark Nottingham m...@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. 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. A quick search of Google code [1], Github [2][3], and Bitbucket [4][5] would indicate otherwise, IMO. For example, the TinyMCE WYSIWYG editor that is included in every Wordpress installation (currently estimated at 65,787,814 sites [6]) uses localStorage for auto-saving blog posts (not exactly bleeding-edge stuff). TinyMCE also boasts some of the most successful and popular sites on the web as users [7]. And that's just one single project from the many thousands of open source projects hosted by Google Code, Bitbucket or Github. [1] http://www.google.com/codesearch#search/q=%5Blocal%7Csession%5DStorage%20lang:%5Ejavascript$type=cs [2] https://github.com/search?type=Everythinglanguage=JavaScriptq=localStorage [3] https://github.com/search?type=Everythinglanguage=JavaScriptq=sessionStorage [4] https://www.google.com/search?hl=enq=site%3Abitbucket.org%20localStorage [5] https://www.google.com/search?hl=enq=site%3Abitbucket.org%20sessionStorage [6] http://en.wordpress.com/stats/ [7] http://www.tinymce.com/enterprise/using.php Regards, -- Mike Taylor Opera Software
Revising Web Storage, was: Re: TAG Comment on
On 11/20/11 7:27 PM, Mike Taylor wrote:
On Sun, 20 Nov 2011 18:30:15 -0500, Mark Nottingham m...@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.
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.
A quick search of Google code [1], Github [2][3], and Bitbucket [4][5]
would indicate otherwise, IMO. For example, the TinyMCE WYSIWYG editor
that is included in every Wordpress installation (currently estimated
at 65,787,814 sites [6]) uses localStorage for auto-saving blog posts
(not exactly bleeding-edge stuff). TinyMCE also boasts some of the
most successful and popular sites on the web as users [7]. And that's
just one single project from the many thousands of open source
projects hosted by Google Code, Bitbucket or Github.
I'm a full-stack polyfill over here. From the bare bones of the
server-side to the legacy hacks of the client.
As I voiced earlier in this thread: I'd rather extend than rewrite.
localStorage could use a Blob storage mechanism. I could really use
that. The FileSystem API is completely inappropriate for most blob
storage needs and other APIs fail support Blob's in an efficient manner.
Is there some reason why I can't have a blob extension to local
storage: localStorage.setBlob('key', BlobData);
As for existing code bases: localStorage throws errors. Few people are
going around with try { localStorage['key'] = 'value'; } catch(e) {}
statements. Though people are certainly testing for the presence of
localStorage, it's rather assumed that if it is present, it can be
written to, with at least a few hundred kilobytes of textual data. That
assumption will break if the API is dropped or significantly altered.
In subsequent APIs, like IndexedDB, spec editors took care to avoid that
error throwing situation.
...
Web Storage is very different from typical storage. It's not an
expectation for a web app that it'll actually have space to store data.
There's no guarantee the data will persist. We do not yet have mount
points, to stash data on the user's file system in a manner that the
user and the OS understand.
Storage is as transient as client-side cookies. With a few clicks, I can
accidentally clear out saved files when I'm just trying to reset my
cache. My databases may become corrupt when the browser crashes on a
complex page I'm testing. I have no easy way to back up my data as I
do with most files on my computer. I can't just copy and paste files
into a new directory.
Web storage is fault-oriented. It's supposed to fail. It's designed for
failure. It's up to application authors and UA vendors to decide what
kind of value-added services they want to give to their users, to help
back up data. It's up to users to take opportunities to copy data out
themselves and archive it in their own manner. This is stressful to me,
as a developer, because Apple, Google can wipe out a business model in
any given browser release, but that's the business we're in.
I am bringing this up to point out that, although web storage is out
there, in production, there's room to destroy data. It's not a happy
situation, and it's one that many developers will learn the hard way (as
I did). But once it's accepted, it's easier to understand how to use web
storage in a safe manner.
-Charles
Re: TAG Comment on
On Mon, Nov 21, 2011 at 8:57 AM, Mike Taylor mi...@opera.com wrote: A quick search of Google code [1], Github [2][3], and Bitbucket [4][5] would indicate otherwise, IMO. For example, the TinyMCE WYSIWYG editor that is included in every Wordpress installation (currently estimated at 65,787,814 sites [6]) uses localStorage for auto-saving blog posts (not exactly bleeding-edge stuff). TinyMCE also boasts some of the most successful and popular sites on the web as users [7]. And that's just one single project from the many thousands of open source projects hosted by Google Code, Bitbucket or Github. That would still form a very small percentage of usage on the web. I dont think the usage is still in double digit percentage on the Web. So a change is still feasible. regards Vivek -- The hidden harmony is better than the obvious!!
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
Could you quantify widely? On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com 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 Mendelsohn n...@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/
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/
Re: TAG Comment on
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 n...@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/
RE: TAG Comment on
From: ext Glenn Adams [gl...@skynav.com] Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.commailto:w...@adambarth.com 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.
Re: TAG Comment on
Extend, not delete. On Nov 15, 2011, at 3:51 PM, ashok malhotra ashok.malho...@oracle.com wrote: 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/
Re: TAG Comment on
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. On Tue, Nov 15, 2011 at 5:21 PM, art.bars...@nokia.com wrote: * From:* ext Glenn Adams [gl...@skynav.com] * * Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com 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.
Re: TAG Comment on
On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@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. ~TJ
Re: TAG Comment on
* Tab Atkins Jr. wrote: On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@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. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
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.
