On Sat, Mar 28, 2009 at 11:29 AM, Michael Nordman wrote:
> On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson 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 that the fact that both th
> 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 wrote:
>
>
> On Tue, Mar 24, 2009 at 2:11 AM, Ian Hi
On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson 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 how
>
On Tue, Mar 24, 2009 at 10:11 PM, Ian Hickson 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 implement
somethi
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
*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 c
On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow 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
> general unrespo
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
bef
On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow 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 implemenation is co
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow 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 implemenation is conc
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow 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 implemenation is c
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 8:07 AM, Michael Nordman wrote:
> 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 or
localStorage
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
t
On Sun, Mar 22, 2009 at 11:53 AM, Aaron Boodman wrote:
> On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson 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 instea
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson 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
> change the API to
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson 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 about this more, a
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 s
On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman wrote:
> On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking 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 m
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking 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
> multi-process
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 9:41 AM, Drew Wilson 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 will be a big prob
On Sat, Mar 21, 2009 at 9:38 AM, Aaron Boodman wrote:
> On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking 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 localStor
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson 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 could use the sa
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 wrote:
> On Fri, Mar 20, 2009 at 3:10
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking 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. This would
On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman 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 such a simple
On Fri, Mar 20, 2009 at 3:34 PM, Dmitry Titov wrote:
> On Fri, Mar 20, 2009 at 2:39 PM, Drew Wilson 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
On Fri, Mar 20, 2009 at 2:39 PM, Drew Wilson 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 access
> it, but it'
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:19 PM, Oliver Hunt wrote:
>> When discussing this standard we have to recognize that not all
>> browsers actually have a "main thread".
>
> Yes they do -- we're talking about the main thread from the point of view of
> javascript, which is not necessarily the UI thread.
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 ope
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 th
On Fri, Mar 20, 2009 at 1:47 PM, Jonas Sicking wrote:
> On Fri, Mar 20, 2009 at 1:23 PM, Jeremy Orlow 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
On Fri, Mar 20, 2009 at 1:23 PM, Jeremy Orlow 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
> could build t
I'm currently implementing window.localStorage (
http://dev.w3.org/html5/webstorage/#storage) in Chromium. While figuring
out how to handle concurrency, the issue of integration with workers came
up. The big problem is that there are many valid/good uses of workers that
could not be used in conju
36 matches
Mail list logo
