Fwd: Re: Please review the updated Streams API

[Harald Alvestrand]

Rob Manson sent out a request to the WEBRTC WG's mailing list for review 
of the implications of the Stream API to WEBRTC.


Arthur Barstow asked for comments to be sent to public-webapps@w3.org, 
so I'm forwarding my response here.



 Original Message 
Subject:Re: Please 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 
To: Rob Manson , public-web...@w3.org



Thank you for posting the link.

As written, this specification shows how to send an uninterpreted,
unsegmented stream of bytes over an API interface.

Since none of our interfaces (except possibly the output of the Recorder
interface) is specified in terms of uninterpreted, unsegmented streams
of bytes, I don't think this is particularly useful to the APIs
specified by this working group.

Thank you very much for explicitly naming the types you're specifying
'ByteStream' so that it is trivial to see that this is the abstraction
that this specification is relevant to.

On 12/05/2013 11:06 AM, Rob Manson wrote:

Hi,

if you didn't see my earlier post to public-media-capture, there's an
updated W3C Streams API draft available for review and I've been asked
to also notify this WG to get your feedback on it's implications for
MediaStream, MediaStreamTrack, RTCPeerConnection and RTCDataChannels.

https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

I'd encourage you all to review it and provide any feedback or
thoughts you might have.

As I mentioned in my post to public-media-capture, Feras and Takeshi
have been doing a great job integrating and filtering all the feedback
they've received and I've personally been pushing for as much focus on
making it as effective and useful for post-processing as possible. I'm
sure many of you here have a different perspective they would find
very valuable.

Below is the email Feras sent to describe where this work is up to.

roBman



On 12/4/13 11:27 AM, ext Feras Moussa wrote:
The editors of the Streams API have reached a milestone where we feel
many of the major issues that have been identified thus far are now
resolved and incorporated in the editors draft.

The editors draft [1] has been heavily updated and reviewed the past
few weeks to address all concerns raised, including:
1. Separation into two distinct types -ReadableByteStream and
WritableByteStream
2. Explicit support for back pressure management
3. Improvements to help with pipe( ) and flow-control management
4. Updated spec text and diagrams for further clarifications

There are still a set of bugs being tracked in bugzilla. We would like
others to please review the updated proposal, and provide any feedback
they may have (or file bugs).

Thanks.
-Feras


[1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

Re: Missing Features: Stream Control

[Harald Alvestrand]

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 that people need to focus on: 
stop() is permanent, .enabled can be switched back and forth.




>> know the difference between pause and a broken connection

Good point.



On 19 October 2013 00:42, Aymeric Vitte > wrote:


What I am saying here is that there should be an unique and
unified Streams API supported by all related APIs, each group
where it is relevant should feel concerned instead of thinking
another one might be.

Le 18/10/2013 20:04, Adam Roach a écrit :

On 10/18/13 12:47, Aymeric Vitte wrote:


Le 18/10/2013 19:13, Adam Roach a écrit :

To be clear, the .enabled flag and .stop() method are
already there, and they already pause/unpause the
stream and tear it down, respectively. I'm just
proposing concrete semantics for how they interact
with any PeerConnection that the track is associated with.


But they are not in the Streams proposal, see my other answer.


To make my point clearer: this isn't the right mailing list to
talk about making changes to the API on MediaStream and
MediaStreamTrack. If I had been proposing to change those
APIs, it would have been on the public-media-capture list, not
the public-webrtc list.

All I was trying to talk about is how the existing API
influences the behavior of RTCPeerConnection, which is why I
was talking about it on this list. If you want to propose
changes to MediaStream and MediaStreamTrack, please take them
to public-media-capture.

/a


-- 
Peersm : http://www.peersm.com

node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Extending createObjectUrl to MediaStream?

[Harald Alvestrand]

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 someone else (perhaps via
an iFrame). If the MediaStream is a transferable object the incoming
MediaStream can be transferred to the main page, which in turn can
control layout and rendering.


One interesting thing about a MediaStream is that it's got multiple 
links to the world around it. In particular, it can be connected to 
multiple downstream objects.
This means that what happens to its peers when one transfers it has to 
be defined.


For instance, if MediaStream were transferable, could I do this?

GetUserMedia(., success, failure)

function success(stream) {
   myVideoTag.srcObject = stream
   stream.transfer(myWorker)
}

and after this - would the video stop playing (because the stream is 
gone from my context), or not?

Re: [File API] Blob URI creation

[Harald Alvestrand]

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 object passed to it 
before deciding what to do about it. This means that you either mock out 
or override the function on Window (having to pass through the 
functionality for all other types than the one you're mocking), or 
you're sharply limited in what you can mock.


If createObjectURL was *defined* (for backwards compatibility) as

window.createObjectURL = function(object) {
return object.url
}

a mock that "behaved like a File" or "behaved like a MediaStream" would 
be far simpler to write, with much less chance of affecting other 
behaviour than that of the specific mocked-out type.








On 05/30/2012 06:09 PM, Rich Tibbett wrote:

Hi,

Right now we call window.URL.createObjectURL to obtain a Blob URI.

As a developer I'd like Blob URI creation functions to hang off the 
Blob interface directly making things a bit simpler and more intuitive.


It seems like we could be far less verbose in Blob URI creation by 
making a Blob.url method that would return a new, unique, one-time 
only Blob URI at all times. That means we won't have long-lived Blob 
URIs living in a document and developers won't need to call 
revokeObjectURL on Blob URIs obtained in this way.


The first time any resulting Blob URI is dereferenced then user agents 
would automatically revoke the associated Blob URI, preventing reuse 
elsewhere. If the web app needed a new Blob URI to use elsewhere they 
would call Blob.url again to obtain a new, unique, one-time only Blob 
URI.


It's not obvious that we should let Blob URIs hang around indefinitely 
or make developers responsible for calling revokeObjectURL manually. 
Since the creation of a Blob URI seems to have relatively little 
overhead, it seems reasonable that we could create a new Blob URI each 
time .url is called.


I wrote a quick Blob.url shim that should help to demonstrate this 
proposal:


http://jsfiddle.net/MV233/

The same addition would apply for MediaStream (i.e. MediaStream.url) 
though the spec says createObjectURL only takes a Blob object at the 
moment (which seems wrong but that is what I'm working to).


This API method could alternatively be called .getURL or .createURL. 
The method does return dynamic content and it does seem to act more 
like a method than an attribute so that would make sense IMO.


At best this would be a replacement for window.URL.createObjectURL. At 
worst, it's a convenient shortcut for developers to creating and using 
no-nonsense Blob URIs.


--
Rich Tibbett
Opera Software ASA

Numeric constants vs enumerated strings

[Harald Alvestrand]

*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) which 
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 the WebIDL community has been strongly in favour of using 
strings, possibly in the form of the newly added WebIDL "enum" 
construct", for these arguments.
However, the developers we're targeting will also be using many other W3 
APIs.


It seems that JavaScript APIs that deal with data flows in some form 
mostly use numeric constants, for instance, XMLHttpRequest, the 
Websocket API, HTMLTrackElement for timed text tracks, HTMLMediaElement 
for  and , various File APIs, the Indexed Database API, 
they all use "readyState" and it's always a numeric value.


So - we're interested in the advice of the community: What should we do? 
Be consistent, or be forward-looking?


A clear answer, if it exists, seems to be beyond the WEBRTC chairs.

 Harald and Stefan, for the WEBRTC WG

(note: we set public-script-co...@w3.org as the "reply-to" address on 
this mail, in order to avoid having a multi-mailing-list discussion. But 
the subject is concerning also for webapps and HTML, and possibly 
others, so we wanted to make sure they know we're asking. Feel free to 
share with others if you feel they need to be brought into the discussion.)


*

Worry on Enum type - binding seems inconsistently defined

[Harald Alvestrand]

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 ECMAScript binding, assignment of an invalid string value to 
anattribute is 
ignored, while passing such a value as anoperation 
argument results in 
an exception being thrown.


However, in the ECMAScript binding, section 4.2.18, it says:


An ECMAScript value V is converted to an IDL enumeration type value as 
follows (where E is the enumeration):


1. Let S be the result of calling ToString(V).
2. If S is not one of E's enumeration values, then throw a TypeError.
3. Return the enumeration value of type E that is equal to S.

I'm not sure it says the same thing; more clarity on the expected 
behaviour would be useful.
(My personal opinion is that it's most useful if assigment throws an 
exception; silent failure is rarely the best option.)


Although other bindings don't really matter so much, I would also think 
that it was a Good Thing if the spec gave advice saying that all 
bindings should detect value errors at assignment time, and signal 
errors appropriately for that language, rather than leaving the decision 
to binding designers.


That's all my worry

Harald