Now that Web Storage spec has been split out, there are several parts of the
Web Worker spec that should no longer point at the HTML 5 spec. An example
is the following section, but I'm sure there are others:
http://dev.w3.org/html5/workers/#apis-defined-in-other-specifications).
J
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
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
before? If so, what were the drawbacks?
On Mon, Mar 23, 2009 at 2:24 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
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
and starting to cause some messy issues there. #3 and #4
preserve the simplicity of localStorage for the simple/common case--which is
important above else, in my opinion.
On Mon, Mar 23, 2009 at 2:48 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow jor
On Wed, Apr 1, 2009 at 3:17 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Apr 2, 2009 at 11:02 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
(Note that you can provide hen read-only scripts are easy to optimize for
full parallelism using )
Oops!
I was going to point out
On Tue, Mar 31, 2009 at 9:57 PM, Drew Wilson atwil...@google.com wrote:
On Tue, Mar 31, 2009 at 6:25 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
We don't know how much (if any) performance must be sacrificed, because
no-one's tried to implement parallel cookie access with
On Thu, Apr 2, 2009 at 6:37 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
Unfortunately we have to deal with cookies and localStorage, where the API
is already set.
Is it set?
I understand that localStorage has been around for a while, but as far as I
can tell virtually no one uses it.
On Fri, Apr 3, 2009 at 2:18 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan
rob...@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
On Fri, Apr 3, 2009 at 2:25 PM, Drew Wilson atwil...@google.com wrote:
If we can capture the correct behavior using synchronous APIs, we should.
I think we already have a good, correct, synchronous API. My concern is the
implications to the internals of the implemenation.
Anyway, given that
I created a page that sets a variable in sessionStorage, then I navigated to
a different domain, then I went back to the page and checked if the variable
was still set. In Safari 4 (beta) it is. In IE8 it isn't.
The spec is not terribly clear: When a top-level browsing context is
destroyed (and
On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow jor...@google.com wrote:
People are now talking about specifying this, but there's been push back.
Also, there's no way to guarantee serializability for the network
On Fri, Apr 3, 2009 at 3:16 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 3 Apr 2009, Jeremy Orlow wrote:
I created a page that sets a variable in sessionStorage, then I
navigated to a different domain, then I went back to the page and
checked if the variable was still set. In Safari 4
On Fri, Apr 3, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote:
Hmm...
In Chrome we also create a new browsing context when the user types a new
URL into the location bar of an existing tab. This can be thought of as a
shortcut for create a new tab with the given URL and close the old
I think this also applies: NOTE: The lifetime of a browsing context can be
unrelated to the lifetime of the actual user agent process itself, as the
user agent may support resuming sessions after a restart.
On Fri, Apr 3, 2009 at 6:46 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 3 Apr 2009,
I haven't decided for sure yet, but I was leaning towards either option #2
or option #3 for Chrome. Option 5 seems like it'll be very confusing to
apps. It's possible it'll even have undesired consequences like websites
popping up alerts or telling the user you need to increase your quota and
On Tue, Apr 7, 2009 at 6:33 PM, Brady Eidson beid...@apple.com wrote:
On Apr 7, 2009, at 6:24 PM, Jeremy Orlow wrote:
Both would lead to bizarre behavior where data that the application
thought was saved really wasn't.
This matches up with how most private browsing sessions handle cookies
2009/4/7 Michael Nordman micha...@google.com
I'm not sure this has to be addressed in the standard. This seems like
something browser developers can address without grand unification.
They can, but then it shifts burden onto web developers to test more or
users to deal with broken websites.
2009/4/7 Jonas Sicking jo...@sicking.cc
2009/4/7 Ian Fette (イアンフェッティ) ife...@google.com:
2009/4/7 Jonas Sicking jo...@sicking.cc
2009/4/7 Ian Fette (イアンフェッティ) ife...@google.com:
In Chrome/Chromium, incognito mode is basically a new profile that
is
in
memory (plus or minus... the
On Tue, Apr 7, 2009 at 8:39 PM, timeless timel...@gmail.com wrote:
2009/4/8 Jeremy Orlow jor...@google.com:
If a user is in private browsing mode typing up a message, they should
definitely not expect it to be there when they leave such a mode. If
they
do expect
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x) { alert(Wait, this works?);
};
window.sessionStorage.removeItem('blah');
alert(typeof window.sessionStorage.removeItem);
Safari shows 2 alerts, and the second one says 'function'.
IE8 says object
behavior is correct (a bit weird, but
correct). But this is an area where there isn't good interop right now
across the board.
- a
On Tue, May 26, 2009 at 7:44 PM, Jeremy Orlow jor...@google.com wrote:
No one else (especially from Mozilla or Microsoft)? I was hoping to get
a
consensus
On Tue, May 26, 2009 at 8:28 PM, Aaron Boodman a...@google.com wrote:
On Tue, May 26, 2009 at 8:17 PM, Jeremy Orlow jor...@google.com wrote:
What's special here is that everything set with the implicit
getters/setters
is supposed to be turned into a string. So yes this does seem somewhat
On Wed, Jun 3, 2009 at 1:15 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Apr 2009, Honza Bambas wrote:
In the W3C spec for localStorage
http://dev.w3.org/html5/webstorage/#the-localstorage-attribute is said
to present it (the persistent storage) the same way as cookies.
There were
*Please, keep this on topic. There's no point to rehashing
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.htmlor
any of the other similar debates on private browsing and
localStorage's
persistence guarantees.*
When in private browsing mode, WebKit should not write any data
On Tue, Jun 9, 2009 at 6:28 PM, Oliver Hunt oli...@apple.com wrote:
I believe that this will be difficult to have such a limit as sites may
rely on GC to collect Workers that are no longer running (so number of
running threads is
non-deterministic), and in the context of mix source content
On Sat, 23 May 2009, Mike Wilson wrote:
I was thinking about the resubmit problem in a general
context, specifically how browsers could make it possible
for web authors to create POSTing pages that avoids giving
the dreaded do you want to resubmit question at all,
independent of
On Thu, Jun 11, 2009 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 22 May 2009, Jeremy Orlow wrote:
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x) { alert(Wait, this
works?); };
window.sessionStorage.removeItem('blah
On Thu, Jun 11, 2009 at 12:36 PM, Jeremy Orlow jor...@google.com wrote:
On Thu, Jun 11, 2009 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 22 May 2009, Jeremy Orlow wrote:
What is the behavior of the following supposed to be?
window.sessionStorage.removeItem = function(x
On Thu, Jun 11, 2009 at 2:05 PM, Jeremy Orlow jor...@google.com wrote:
On Thu, Jun 11, 2009 at 12:36 PM, Jeremy Orlow jor...@google.com wrote:
On Thu, Jun 11, 2009 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 22 May 2009, Jeremy Orlow wrote:
What is the behavior of the following
Seems like a reasonable idea. I don't know if it's been brought up before.
My guess is that Ian will say this should be re-examined for HTML6, though.
J
On Fri, Jun 19, 2009 at 9:07 PM, Joseph Pecoraro joepec...@gmail.comwrote:
It sounds like there wasn't any discussion on this. I recently
Is it too late? It seems as though Joseph's suggestion could be in addition
to what's already in the spec.
On Tue, Jun 23, 2009 at 2:54 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 22 Jun 2009 18:45:34 +0200, Jeremy Orlow jor...@chromium.org
wrote:
Seems like a reasonable idea. I
On Tue, Jul 7, 2009 at 9:37 AM, SA Alfonso Baqueiro abaque...@gmail.comwrote:
In the lack of agreement.
Instead of removing the video section from the spec, we should be
DEMOCRATIC, the codec that more vendors support should get in the spec, like
the goverments are elected.
In this case
On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson i...@hixie.ch wrote:
1) The 'readyState' attribute can never actually be used by an
application
and is redundant.
Initially, the 'readyState' attribute is set to CONNECTING, but while
the object is in this state the user is not permitted to
On Sun, Jul 26, 2009 at 8:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 26, 2009, at 9:27 PM, Manu Sporny wrote:
Maciej Stachowiak wrote:
I would also caution that, by their nature, standards projects are not
quite the same thing as software projects. While the way HTML5 has been
On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an appropriate
answer. Often, the TCP implementation takes a part of data given to it, and
asks to resubmit
On Mon, Jul 27, 2009 at 1:44 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov a...@webkit.orgwrote:
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree that this will help if the application sends data in burst mode,
but what if it just
On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
If it's only for debugging purposes, maybe a cleaner way to define it is
to simply be the last event fired on a given WebSocket?
I don't really understand what problem we would
On Tue, Jul 28, 2009 at 8:57 PM, Alexey Proskuryakov a...@webkit.org wrote:
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another URL.
I'm not sure if the intention is to leave this to implementations, or to
add in Web Sockets v2,
On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson m...@google.com wrote:
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.jackalm...@gmail.com
wrote:
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidsonm...@google.com wrote:
With a hidden page that's accessible to all Google Finance visible
On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平 shumpei.shirai...@gmail.com wrote:
Hi,
I'm implementing the HTML5 Web Storage using Gears
(http://code.google.com/p/gear5/), so I have several questions with
the spec.
-Storage.setItem(key, val)
--is key allowed non-string type object?
Yes, but...
On Wed, Aug 12, 2009 at 1:34 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Aug 2009, į~Y―į~_ģäŋ~Jåđģ wrote:
and, when passed value is undefined (e.g. `setItem(key)`), which
behavior will be correct?
On current implementation of browsers, I looked as follows.
- IE and Firefox raise
On Wed, Aug 12, 2009 at 4:26 PM, Cameron McCormack c...@mcc.id.au wrote:
Boris Zbarsky:
Given the actual example code (and not its description, which
doesn't match the code), the relevant section is
http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through
3 in the third bullet
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson i...@hixie.ch wrote:
Additionally, any server-side-feed-based solution has the implication
that it won't work for offline apps. If I am using a web calendar, I
want my event notifications regardless of whether I'm online or offline
(the event
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 7 Aug 2009, Jonas Sicking wrote:
I agree that these are very interesting features. Especially connection
multiplexing is something that I think is a good idea, for the reasons
you've mentioned elsewhere in this
On Fri, Aug 14, 2009 at 4:06 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 9 Aug 2009, Jeremy Orlow wrote:
I feel like redirects add unnecessary complexity.
We're already asking application developers to handle ACKing, keep
alives, multi-plexing, connection limiting, authentication, etc
On Tue, Aug 18, 2009 at 12:32 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com
wrote:
Threading:
This is the unavoidable question
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
On Tue, Aug 18, 2009 at 1:22 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 18, 2009 at 12:00 AM, Darin Fisherda...@chromium.org wrote:
I agree. Moreover, since a shared worker identified by a given name
cannot
be navigated elsewhere, the name isn't all that synonymous with other
I was looking through the WebStorage and HTML 5 specs regarding the storage
mutex. I have a few comments/questions.
First of all, I was wondering why all user prompts are specified as must
release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really
I just ran into a short but sweet document that I found helpful but that I
had never seen mentioned on this list:
http://wiki.whatwg.org/wiki/How_to_write_a_spec I figured there was enough
of a chance that someone else would find it helpful or others would have
information to contribute that it
On Tue, Aug 18, 2009 at 5:04 PM, Justin Lebar justin.le...@gmail.comwrote:
I'm in the process of implementing the HTML5 History API
(History.pushState(), History.clearState(), and the PopState event) in
Firefox. I'd like to discuss whether the API might benefit from some
changes. To my
I see. It makes more sense why you mentioned the session storage element
then. Note that there has been some discussion about whether session
storage should survive crashes, but I know Safari and Chrome are currently
planning to _not_ serialize it to disk.
I don't have any good use cases for
On Thu, Aug 20, 2009 at 3:13 PM, Justin Lebar justin.le...@gmail.comwrote:
On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlowjor...@chromium.org wrote:
I see. It makes more sense why you mentioned the session storage element
then. Note that there has been some discussion about whether session
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.org wrote:
Btw, storing a GUID and using session storage really isn't useful since
session storage itself only stores strings.
Btw, I lied. This part of the spec just changed, so now DOM Storage can
store anything that supports
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what
On Fri, Aug 21, 2009 at 12:26 PM, Mike Wilson mike...@hotmail.com wrote:
Justin Lebar wrote:
Mike Wilson wrote:
Sorry, it seems we are not talking about the same application.
Jonas referred to attachment pages in your bug database, which
I assumed would f ex be a page like this one:
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote:
It's also worth noting that Chromium is probably going to need to drop the
storage mutex for most if not all plugin related calls due to deadlock
conditions. If there were some place to mention this as a may type thing
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage collect any local state. If they can't then
attackers (or the merely lazy)
On Tue, Aug 25, 2009 at 2:16 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage
On Tue, Aug 25, 2009 at 2:40 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-)
Does
anyone outside of Apple and Google have an opinion on the matter (since
On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Extensions are an example
On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.orgwrote:
To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data. I think many
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob
Is there any data (or any way to collect the data) on how much of the web IE
and Chrome's current behavior has broken? Given that there hasn't been
panic in the streets, I'm assuming approximately 0%?
Given that web developers have never had any guarantees for cookie
access/setting in terms of
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.org wrote:
Is there any data (or any way to collect the data) on how much of the web
IE and Chrome's current behavior has broken? Given
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote:
I started writing a detailed rebuttal to Linus's reply, but by the time I
was finished, many others had already delivered more targetted replies.
So I'll cut the rebuttal format and make a few specific points.
- Many
2009/8/27 Michael Nordman micha...@google.com
2009/8/27 Jonas Sicking jo...@sicking.cc
2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com:
I would much rather have a well thought-out local filesystem proposal,
than
continued creep of the existing File and Local Storage proposal. These
Can anyone from Firefox speak to whether this should be considered a bug
(I'm happy to file) or whether this behavior is intended?
On Thu, Aug 27, 2009 at 3:39 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Aug 26, 2009, at 22:54, Darin Fisher wrote:
Firefox and IE implement window modal, which
On Fri, Aug 28, 2009 at 4:05 AM, Kevin Benson kevin.m.ben...@gmail.comwrote:
On Sun, Aug 23, 2009 at 1:22 AM, Jeremy Orlowjor...@chromium.org wrote:
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org
wrote:
Lastly, is navigator.getStorageUpdates() the right name
On Mon, Aug 31, 2009 at 11:18 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.orgwrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread
On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson mike...@hotmail.com wrote:
David Bennett wrote:
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.com wrote:
This would be my inclination as well. I'm not entirely convinced that
every web app should define their own idle timeout is
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.orgwrote:
Is there any data (or any way to collect the data) on how much
On Thu, Sep 3, 2009 at 4:50 AM, Jens Alfke s...@google.com wrote:
On Sep 2, 2009, at 11:36 AM, Peter Kasting wrote:
It still seems like you are interpreting this statement as saying that the
UA must not allow users to keep/clear cookies separately from Local Storage
data.
Yes; that
On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
What kind of conflict? There is no need to merge individual cookies:
whichever one was set (or removed) last wins.
I think this strategy would work fine for cookies since the HTTP side of
them is inherently racy. I
On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson atwil...@google.com wrote:
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
And to be clear: I don't have
On Fri, Sep 4, 2009 at 2:24 AM, timeless timel...@gmail.com wrote:
On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult database api for all storage needs, and to roll
their own change event
On Fri, Sep 4, 2009 at 10:59 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult
For the record, I'm perfectly happy with WebSockets not being made any more
complicated for v1 (i.e. no multi-plexing), but I don't think your arguments
against it are compelling at all, so I'm going to play devils advocate:
On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, Sep 4, 2009 at 4:02 PM, Chris Jones cjo...@mozilla.com wrote:
I'd like to propose that HTML5 specify different schemes than a conceptual
global storage mutex to provide consistency guarantees for localStorage and
cookies.
Cookies would be protected according to Benjamin Smedberg's
On Tue, Sep 8, 2009 at 4:54 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
On Tue, Sep 8, 2009 at 5:20 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8,
On Tue, Sep 8, 2009 at 5:33 PM, Aaron Boodman a...@google.com wrote:
On Tue, Sep 8, 2009 at 1:20 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8,
On Tue, Sep 8, 2009 at 5:35 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:25 AM, Jeremy Orlowjor...@chromium.org wrote:
On Tue, Sep 8, 2009 at 5:20 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodmana...@google.com wrote:
On
.
On Tue, Sep 8, 2009 at 6:02 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Tue, Sep 8, 2009 at 8:38 PM, Jeremy Orlow jor...@chromium.org wrote:
To be clear, Chrome is not going to implement the storage mutex with
respect to cookies, but we are going to implement it for LocalStorage
On Tue, Sep 8, 2009 at 6:38 PM, Aaron Boodman a...@google.com wrote:
On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahanrob...@ocallahan.org
wrote:
Looking back over previous threads on the storage mutex, I can't seem to
remember or find the reason that implementing the storage mutex for
On Wed, Sep 9, 2009 at 4:39 AM, Chris Jones cjo...@mozilla.com wrote:
Aaron Boodman wrote:
On Tue, Sep 8, 2009 at 11:23 AM, Chris Jonescjo...@mozilla.com wrote:
In general, I agree with Rob about this proposal. What problem with
storage
mutex as spec'd today does your proposal solve?
On Wed, Sep 9, 2009 at 9:54 AM, Maciej Stachowiak m...@apple.com wrote:
On Sep 8, 2009, at 4:10 PM, Jonas Sicking wrote:
On Tue, Sep 8, 2009 at 4:00 PM, Maciej Stachowiakm...@apple.com wrote:
On Sep 8, 2009, at 1:35 AM, Jonas Sicking wrote:
I think Firefox would be willing to break
Great analysis. I only have a few comments/questions:
On Wed, Sep 9, 2009 at 1:41 PM, Chris Jones cjo...@mozilla.com wrote:
Jeremy Orlow wrote:
On Wed, Sep 9, 2009 at 4:39 AM, Chris Jones cjo...@mozilla.com mailto:
cjo...@mozilla.com wrote:
Aaron Boodman wrote:
On Tue, Sep 8
In general this seems like a pretty interesting idea. It definitely would
be nice to completely abstract away all concepts of concurrency from web
developers, but some of our solutions thus far (message passing, async
interfaces, etc) have not been terribly appreciated by developers either.
The
On Thu, Sep 10, 2009 at 1:59 AM, Chris Jones cjo...@mozilla.com wrote:
Jeremy Orlow wrote:
What failures could there be in a pesimistic/queue model?
I'm trying to think of a universal failure, something that could arise in
any implementation of any proposal. I think that universal failure
On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodmana...@google.com wrote:
I see.
So you are suggesting the localStorage could have zero concurrency
On Thu, Sep 10, 2009 at 1:37 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman a...@google.com wrote
On Fri, Sep 11, 2009 at 9:28 AM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher da...@chromium.org wrote:
I think there are good applications for setting a long-lived lock.
On Fri, Sep 11, 2009 at 11:52 AM, Darin Fisher da...@chromium.org wrote:
Also, the other motivating factor for me is access to LocalStorage from
workers. (I know it has been removed from the spec, but that is
unfortunate, no?)
This was only done because the storage mutex was added in. Now
the localStorage mutex plus onbeforeunload plus Database
transaction collision equal deadlock?, etc.
I don't think that is what Jeremy was saying (emphasis mine):
On Fri, Sep 11, 2009 at 1:26 AM, Jeremy Orlow jor...@chromium.org wrote:
In theory. In practice, once a vendor has shipped something
1 - 100 of 159 matches
Mail list logo
