[whatwg] Worker feedback

Jeremy Orlow jorlow at google.com
Fri Apr 3 10:35:26 PDT 2009


On Fri, Apr 3, 2009 at 2:18 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan <
> robert at ocallahan.org> wrote:
>
>> Mozilla could probably get behind that, but I don't know who else is
>> willing to bite the bullet.
>>
>
> The problem already exists for document.cookie, no? And the current API is
> by far the most convenient the use.


If I understood the discussion correctly, the spec for document.cookie never
stated anything about it being immutable while a script is running.  People
are now talking about specifying this, but there's been push back.  Also,
there's no way to guarantee serializability for the network traffic portion
so I'm guessing (hoping!) that this wouldn't be required in the JavaScript
side, even if it went through.

localStorage, on the other hand, does have language in the draft spec
stating that changes to localStorage must be serialized as if only one event
loop is running at a time.  That's the problem.  In other words, the
strictness of the concurrency control for localStorage is what makes this
different from document.cookie.


As for convenience:

The spec is written in such a way that you can't have more that one event
loop per browser window/worker, and everything is essentially tied to this
one event loop.  In other words, each window/worker can't run on more than
one CPU core at a time.  Thus, the only way for a web application to scale
in todays world is going to be through additional windows and/or workers.

I agree that the current API is quite convenient, but it worries me a great
deal that it's synchronous.  Now that navigator.unlockStorage() has been
added to the spec and you can't access localStorage from workers, I'm less
worried.  But I still feel like we're going to regret this in the next
couple years and/or people will simply avoid localStorage.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090403/be36cf34/attachment.htm>


More information about the whatwg mailing list