- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 07 Jan 2011 16:35:23 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Glenn Maynard <glenn@zewt.org>, public-webapps WG <public-webapps@w3.org>
On 1/6/2011 3:20 PM, Jonas Sicking wrote: > On Thu, Jan 6, 2011 at 3:06 PM, Charles Pritchard<chuck@jumis.com> wrote: >> Shouldn't sessionStorage be made accessible? >> >> I don't think localStorage should be (to web workers), but sessionStorage >> seems >> a reasonable request. > Why wouldn't that have the same threading issues as I described? There a good reason for it to have those issues in sessionStorage. localStorage need not. At least when it comes to workers. They use synchronous interfaces in the File API, too. Would you rather File API be used to create locks? Keep in mind that sessionStorage is limited to 5 megs: these are reasonably small areas of memory, and they're not written to that often. On 1/6/2011 4:19 PM, Glenn Maynard wrote: > On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchard<chuck@jumis.com> wrote: >> Shouldn't sessionStorage be made accessible? >> >> I don't think localStorage should be (to web workers), but sessionStorage >> seems >> a reasonable request. > Why? I've wanted to access localStorage from workers in the past, and > if the details for accessing Storage objects are worked out at all, > then exposing sessionStorage but not localStorage seems arbitrary and > unnecessarily restrictive. > It's not arbitrary: the names "local" and "session" convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. You can still use your main thread to loop through session storage and copy it into local storage.
Received on Saturday, 8 January 2011 00:35:20 UTC