On 1/6/2011 3:20 PM, Jonas Sicking wrote:
On Thu, Jan 6, 2011 at 3:06 PM, Charles Pritchard<ch...@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<ch...@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.
