On Sat, Mar 28, 2009 at 11:29 AM, Michael Nordman micha...@google.comwrote:
On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 20 Mar 2009, Jonas Sicking wrote:
I do think it would be great if workers had access to some type of
structured storage. However I agree
On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson i...@hixie.ch wrote:
I've updated the specs as follows:
- removed localStorage from Web Workers for now.
- extended the implicit lock mechanism that we had for storage to also
cover document.cookie, and made the language more explicit about
sessionLifetime + tabSpecificScope doesn't make much sense since
you get a new set of tabs when starting a new session
Sorry... make that persistentLifetime + tabScope doesn't make sense.
On Fri, Mar 27, 2009 at 3:29 PM, Michael Nordman micha...@google.comwrote:
On Tue, Mar 24, 2009 at
I've updated the specs as follows:
- removed localStorage from Web Workers for now.
- extended the implicit lock mechanism that we had for storage to also
cover document.cookie, and made the language more explicit about how
it works.
- added navigator.releaseLock().
On Fri, 20 Mar
On Tue, Mar 24, 2009 at 10:11 PM, Ian Hickson i...@hixie.ch wrote:
- extended the implicit lock mechanism that we had for storage to also
cover document.cookie, and made the language more explicit about how
it works.
That's basically good. It's possible that people might want to
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser implemenation is concerned, a call to this function
would be the same as the script
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow jor...@google.com wrote:
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser
On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow jor...@google.com wrote:
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser
I really like the idea of some generic yield, though I wonder if there's
some reason it hasn't been added earlier. People have been using the
setTimeout(..., 0) trick for a while to get around slow script warnings (and
general unresponsiveness)...so surely something like this must have come up
On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow jor...@google.com wrote:
I really like the idea of some generic yield, though I wonder if there's
some reason it hasn't been added earlier. People have been using the
setTimeout(..., 0) trick for a while to get around slow script warnings (and
*Given that things have simmered down, it seems like it's time for a re-cap
of the options. I believe this includes all the options currently on the
table (in broad strokes anyhow). If I missed anything or grossly
mischaracterized any idea, feel free to correct me.*
0: Do nothing. As far as I
On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman a...@google.com wrote:
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo...@sicking.cc wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll
risk
The problem is that .length is basically useless without some kind of
immutability guarantees.
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson atwil...@google.com wrote:
The problem is that .length is basically useless without some kind of
immutability guarantees.
Understood, and when you need that guarantee it would be available via the
getLocalStorage(callback) API.
I've thought
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson atwil...@google.com wrote:
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to see us radically
On Sun, Mar 22, 2009 at 11:53 AM, Aaron Boodman a...@google.com wrote:
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson atwil...@google.com wrote:
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to
If you deny workers, you can enforce exclusive access to localStorage by
applying a lock that extends from the first access of localStorage until the
script re-enters the event loop. Page script is guaranteed to re-enter the
event loop fairly quickly (lest it trigger the browser's this script is
On Mon, Mar 23, 2009 at 8:07 AM, Michael Nordman micha...@google.comwrote:
I don't see how denying workers solves the problem. In a multi-threaded
browser, this has to be resolved reasonably even in the absence of workers.
It has to be resolved in a way that doesn't expose asynchronous cookie
On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman a...@google.com wrote:
I think the best option is to make access to localstorage asynchronous
for workers. This reduces the amount of time a worker can hold the
localstore lock so that it shouldn't be a problem for normal pages. It
sucks to make
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
What we could do, is to have an API like
getLocalStorage(callback);
This function returns immediately, but will then call the callback
function as soon as the localStorage becomes available and the lock
been acquired.
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
-atw
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Mar
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote:
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
It seems like they
On Sat, Mar 21, 2009 at 9:38 AM, Aaron Boodman a...@google.com wrote:
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
What we could do, is to have an API like
getLocalStorage(callback);
This function returns immediately, but will then call the callback
function as
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote:
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
I don't think it
As a side note, if we do go with this async lock acquiring, we could
add an API like:
getLockedFeatures(callback, 'localStore', 'cookie');
This would be an asynchronously grab locks to multiple features and
only call the callback once all of them have been acquired. This would
allow computations
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo...@sicking.cc wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll
risk dead-locks.
Say that we make document.cookie behave the same way (to prevent
On Fri, Mar 20, 2009 at 1:23 PM, Jeremy Orlow jor...@google.com wrote:
What is the need for localStorage access within workers? Technically if
someone really needed to access it, they could always have a function in the
web page for accessing it and then use postMessage. In other words, they
On Fri, Mar 20, 2009 at 1:47 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Mar 20, 2009 at 1:23 PM, Jeremy Orlow jor...@google.com wrote:
What is the need for localStorage access within workers? Technically if
someone really needed to access it, they could always have a function in the
When discussing this standard we have to recognize that not all
browsers actually have a main thread. Time will tell if more or less
browsers of the future will have multi-threaded architectures, but the
trend has been for more I think.
Any aspects of the spec that asserts or assumes a main
I agree with Jeremy that the spec is currently unimplementable if we give
localStorage access to workers. I'd like to point out that workers who want
to access localStorage just need to send a message to their main window
breaks down for persistent workers (where you don't necessarily have an open
I think the best option is to make access to localstorage asynchronous
for workers. This reduces the amount of time a worker can hold the
localstore lock so that it shouldn't be a problem for normal pages. It
sucks to make such a simple and useful API aync though.
- a
On Fri, Mar 20, 2009 at 2:39 PM, Drew Wilson atwil...@google.com wrote:
One alternative I'd like to propose is to remove access to localStorage for
dedicated workers, and give SharedWorkers access to localStorage, but have
that storage be partitioned by the worker name (i.e. the worker can
On Fri, Mar 20, 2009 at 3:34 PM, Dmitry Titov dim...@google.com wrote:
On Fri, Mar 20, 2009 at 2:39 PM, Drew Wilson atwil...@google.com wrote:
One alternative I'd like to propose is to remove access to localStorage
for dedicated workers, and give SharedWorkers access to localStorage, but
have
33 matches
Mail list logo
