On Sat, 28 Mar 2009, Robert O'Callahan wrote:
On Sat, Mar 28, 2009 at 2:23 PM, Ian Hickson i...@hixie.ch wrote:
Robert O'Callahan wrote:
Now, with the storage mutex, are there any cases you know of where
serializability fails? If there are, it may be worth noting them in
the spec. If
29.04.2009, в 6:05, Ian Hickson написал(а):
Disregarding charset from HTTP headers is just a weird special case
for
a few text resource types. If we were going to deprecate HTML, XML
and
CSS, but keep appcache manifest going forward, it could maybe make
sense.
What's the advantage of
On Wed, 29 Apr 2009, Alexey Proskuryakov wrote:
29.04.2009, в 6:05, Ian Hickson написал(а):
Disregarding charset from HTTP headers is just a weird special case
for a few text resource types. If we were going to deprecate HTML,
XML and CSS, but keep appcache manifest going forward, it
On Mon, Apr 6, 2009 at 8:57 PM, timeless timel...@gmail.com wrote:
FWIW, iirc multiple processes from IE dates to at least IE4
The best url I can find on the subject atm is
http://aroundcny.com/technofile/texts/bit092098.html.
Michael Nordman micha...@google.com wrote:
There are
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:
If I understood the discussion correctly, the spec for document.cookie
never stated anything about it being immutable while a script is running.
On Mon, 6 Apr 2009, Darin Fisher wrote:
In addition to alert(), don't forget about all the great state changing
things that can happen to the cookie database (and other data stores)
during a synchronous XMLHttpRequest (or synchronous document.load) in
Firefox. Maybe those are just bugs?
On Mon, Apr 6, 2009 at 7:03 PM, Darin Fisher da...@chromium.org wrote:
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:
If I understood the discussion correctly, the spec for document.cookie
On Mon, Apr 6, 2009 at 4:20 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Mon, Apr 6, 2009 at 7:03 PM, Darin Fisher da...@chromium.org wrote:
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
There are additional constraints that haven't been mentioned yet...
Plugins.
The current model for plugins is that they execute in a single-threaded
world. Chrome maintains that model by hosting each plugin in its own process
and RPC'ing method invocations back and forth between calling pages and
On Tue, Apr 7, 2009 at 1:53 AM, Darin Fisher da...@chromium.org wrote:
OK... so if I am building an API, the consumer of my API might not realize
that I have stuck a sync XHR in the middle of it. (People often do that so
that their API can work during unload.) So the consumer of such an API
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.com wrote:
There are additional constraints that haven't been mentioned yet...
Plugins.
The current model for plugins is that they execute in a single-threaded
world. Chrome maintains that model by hosting each plugin in its own
On Mon, Apr 6, 2009 at 7:17 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.comwrote:
There are additional constraints that haven't been mentioned yet...
Plugins.
The current model for plugins is that they execute in a
On Mon, Apr 6, 2009 at 7:28 PM, Michael Nordman micha...@google.com wrote:
On Mon, Apr 6, 2009 at 7:17 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.comwrote:
There are additional constraints that haven't been mentioned
On Tue, Apr 7, 2009 at 5:04 AM, Michael Nordman micha...@google.com wrote:
Consider three threads
PageA
PageB
PluginC
PageA
-grabs storage lock
PluginC
-calls out to PageB (everything in NPAPI is synchronous)
-now waiting for PageB to return
PageB
-while handling the plugins
FWIW, iirc multiple processes from IE dates to at least IE4
The best url I can find on the subject atm is
http://aroundcny.com/technofile/texts/bit092098.html.
Michael Nordman micha...@google.com wrote:
There are additional constraints that haven't been mentioned yet... Plugins.
The current
On Sat, Apr 4, 2009 at 11:17 AM, Jeremy Orlow jor...@google.com wrote:
True serializability would imply that the HTTP request read and write are
atomic. In other words, you'd have to keep a lock for the entirety of each
HTTP request and couldn't do multiple in parallel. When I said there's
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 document.cookie, no? And the current API is
by far the most convenient the use.
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 Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan rob...@ocallahan.org wrote:
I agree it would make sense for new APIs to impose much greater constraints
on consumers, such as requiring them to factor code into transactions,
declare up-front the entire scope of resources that will be accessed,
I know I said I would stay out of this conversation, but I feel obliged to
share a data point that's pertinent to our API design.
The structured storage spec has an asynchronous API currently. There are no
shortage of experienced javascript programmers at Google, and yet the single
biggest piece
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
On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow jor...@google.com wrote:
If I understood the discussion correctly, the spec for document.cookie
never stated anything about it being immutable while a script is running.
Well, there never was a decent spec for document.cookie for most of its
life,
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 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 Fri, Apr 3, 2009 at 9:00 AM, Jeremy Orlow jor...@google.com wrote:
The problem is escalating the lock. If your script does a read and then a
write, and you do this in 2 workers/windows/etc you can get a deadlock
unless you have the ability to roll back one of the two scripts to before
the
On Fri, Apr 3, 2009 at 9:02 AM, Jeremy Orlow jor...@google.com wrote:
I agree with everything Drew said, but I think think this one point really
needs to be singled out. Cookies go across the wire. Serializable
semantics are not possible in todays (latent) world. Period.
The unit of
On Fri, Apr 3, 2009 at 9:02 AM, Jeremy Orlow jor...@google.com wrote:
I agree with everything Drew said, but I think think this one point really
needs to be singled out. Cookies go across the wire. Serializable
semantics are not possible in todays (latent) world. Period.
The unit of
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 5:11 PM, Jeremy Orlow jor...@google.com wrote:
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
I'd like to propose a way forward. Please have an open mind.
The objections your hearing from the chrome world are around the locking
semantics being proposed. In various discussions the terms evil,
troubling, and onerous have been used to describe what we think about
aspects of those semantics.
On Thu, Apr 2, 2009 at 7:18 AM, Michael Nordman micha...@google.com wrote:
I suggest that we can come up with a design that makes both of these camps
happy and that should be our goal here.
To that end... what if...
interface Store {
void putItem(string name, string value);
string
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 that you can use a reader/writer lock to implement
serializability while allowing
On Mon, Mar 30, 2009 at 6:45 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
We have no way of knowing how much trouble this has caused so far;
non-reproducibility means you probably won't get a good bug report for any
given incident.
It's even plausible that people are getting lucky with
On Wed, Apr 1, 2009 at 7:27 AM, Drew Wilson atwil...@google.com wrote:
So, the first argument against cookie races was this is the way the web
works now - if we introduce cookie races, we'll break the web. When this
was proven to be incorrect (IE does not enforce exclusive access to
cookies),
On Tue, Mar 31, 2009 at 6:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
We know for sure it's possible to write scripts with racy behaviour, so the
question is whether this ever occurs in the wild. You're claiming it does
not, and I'm questioning whether you really have that data.
I'm
On Fri, Mar 27, 2009 at 6:23 PM, Ian Hickson i...@hixie.ch wrote:
Another use case would be keeping track of what has been done so far, for
this I guess it would make sense to have a localStorage API for shared
workers (scoped to their name). I haven't added this yet, though.
On a related
On Tue, Mar 31, 2009 at 7:22 AM, Drew Wilson atwil...@google.com wrote:
Re: cookies
I suppose that network activity should also wait for the lock. I've made
that happen.
Seems like that would restrict parallelism between network loads and
executing javascript, which seems like the wrong
I think it makes sense to treat dedicated workers as simple subresources,
not separate browsing contexts, and that they should thus just use the
application cache of their parent browsing contexts. This is what WebKit
does, according to ap.
I've now done this in the spec.
Sounds good.
On Sat, Mar 28, 2009 at 2:23 PM, Ian Hickson i...@hixie.ch wrote:
Robert O'Callahan wrote:
Now, with the storage mutex, are there any cases you know of where
serializability fails? If there are, it may be worth noting them in the
spec. If there aren't, why not simply write serializability
On 28.03.2009, at 4:23, Ian Hickson wrote:
I think, given text/css, text/html, and text/xml all have character
encoding declarations inline, transcoding is not going to work in
practice. I think the better solution would be to remove the rules
that
make text/* an issue in the standards
Scripts, and worker scripts in particular, should use application media
type; using text/javascript is obsolete. [RFC4329#3].
Chris
42 matches
Mail list logo
