On Wednesday, June 22, 2011 3:24 PM, James Robinson wrote: > On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor <simetrical+...@gmail.com> > wrote: > > On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > > Note that there are currently major browsers that do not follow the spec > > > as > > > currently written and have explicitly said that they have no plans to do > > > so. > > If browsers can agree on what to implement, update the spec to reflect > > that. If they can't and we don't think they ever will, update the > > spec to say behavior is undefined. Either way, it's no less worthy of > > REC-track specification than other preexisting features that are > > flawed but in practice not removable from the platform. > > I think browsers are relatively speaking closer in implementation to each > other > than to the spec currently. Would it be too much work to come up with a > specification that did not include the structured clone algorithm and did not > include the storage mutex? That seems to be what browsers need to support for > compatibility, and so it would be ideal to capture that in some form. Such a > specification would have inherent and unavoidable data races (as do current > and future implementations), so it would be a stretch to consider it > "recommended", but it would reflect reality.
I agree - the current API isn't ideal but it is what it is and there is reasonable interoperability at this point. Microsoft would prefer not to see the spec move to WG Note status and instead see the spec modified to reflect the current implementations: removing the SCA, removing the mutex, and adding a warning about the race conditions would get us most of the way. There are certainly uses of this feature where the race is unlikely to cause a problem. Cheers, Adrian.
