- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 4 Mar 2014 09:35:36 +1100
- To: Mark Watson <watsonm@netflix.com>
- Cc: Henri Sivonen <hsivonen@hsivonen.fi>, David Dorwin <ddorwin@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>, "Robert O'Callahan" <robert@ocallahan.org>
We also have this issue for DataCue in the HTML spec [1] with ArrayBuffer, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24687 . I agree we should have a consistent approach. Would it make sense to require cloning on assignment in the IDL spec? Silvia. [1] http://www.w3.org/TR/html5/embedded-content-0.html#datacue On Tue, Mar 4, 2014 at 2:39 AM, Mark Watson <watsonm@netflix.com> wrote: > The same issue exists in WebCrypto. It would be nice to have a > consistent approach across specifications. > > ...Mark > > Sent from my iPhone > >> On Mar 3, 2014, at 3:36 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote: >> >>> On Sat, Feb 22, 2014 at 12:16 AM, David Dorwin <ddorwin@google.com> wrote: >>> I believe there is a similar issue with MSE, and it was decided that such >>> behavior is undefined. >> >> Seems like a bad way to deal with this. >> >>> Does anyone object to the behavior also being >>> undefined for EME? >> >> I object to both MSE and EME introducing a race condition like that. >> IIRC, this issue already came up with Web Audio. CCing roc for the >> details. >> >> I think the method should act as if it made a copy of the data before >> returning. In practice, it probably makes sense to have some sort of >> copy-on-write mechanism behind the scenes to avoid copying when no one >> is actually writing to the original buffer. >> >>> Do we need to explicitly document this anywhere? >> >> Yes! >> >> -- >> Henri Sivonen >> hsivonen@hsivonen.fi >> https://hsivonen.fi/ >> >
Received on Monday, 3 March 2014 22:36:23 UTC