review the updated Streams API
Resent-Date:Sun, 08 Dec 2013 16:10:27 +
Resent-From:public-web...@w3.org
Date: Sun, 08 Dec 2013 17:09:54 +0100
From: Harald Alvestrand har...@alvestrand.no
To: Rob Manson rob...@mob-labs.com, public-web...@w3.org
Thank you for posting the link
On 10/21/2013 12:03 PM, Sam Dutton wrote:
FWIW I think there's some confusion for web devs: whether to use
MediaStream.stop() or MediaStreamTrack.enabled = false. (And, of
course, MediaStream.stop() is 'permanent' -- there's no concept of a
pause.)
True, and I think that's the difference
On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:
On 2013-09-03 01:29, Robert O'Callahan wrote:
What are your use-cases where they're not the same? More importantly,
what are the use-cases where they cannot be made the same by the developer?
E.g. the main page delegating communication to
Hi - just want to say that I support Rich fully in this comment -
createObjectURL is Just Not Right.
I came at this through another pathway - creating mocks in Javascript.
As it is, createObjectURL can't be mocked because it is a function on
Window that is assumed to look at the type of the
*This is a call for help from the WEBRTC working group.
We are defining a new API
(http://dev.w3.org/2011/webrtc/editor/webrtc.html) about:blankwhich
has a number of cases where it needs to use arguments, or expose state
variables, that can take only a limited set of values.
Feedback from
Hello,
the WebRTC WG is currently contemplating following the WebApps WG's
advice on avoiding use of integers in APIs, and switching to enums
whenever possible.
However, one detail makes the spec at this time a bit hard to
understand: In section 3.5, the following is said:
Note
In the
