- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 10 Apr 2012 10:19:09 -0400
- To: public-webrtc@w3.org
On 4/10/2012 5:29 AM, Harald Alvestrand wrote:
> On 04/09/2012 11:31 PM, Cullen Jennings wrote:
>>> - track manipulations: what does it mean to add a
>>> DataMediaStreamTrack to two MediaStreams?
>> I don't think we have full agreement on what this means with media,
>> but again, I would propose same thing. I think this means both streams
>> would get a copy of the data yet only one copy of the data would be
>> sent over the network.
> So the "ondata()" handler will be called twice, once for each
> MediaStream? That's implementable. Is there a situation for which it
> makes sense?
More to the point, what consumes DataMediaStreamTracks? Not <video>
elements... Do we need to define new MediaStream sources and new DOM
elements to be sinks? How or are they bundled with audio/video tracks
in a MediaStream, or are they a separate MediaStream in the remotestream
or localstream lists?
I'm very skeptical of this idea, and it would require a LOT more work to
implement (and a lot more standards-time). IMHO.
>>> Perhaps nothing, since there still can be only one handler (or
>>> handler list) for the onmessage() function anyway?
>>> - "url" and "extensions" attributes from the WebSocket API: Do they
>>> have meaning? Are "extensions" names from the same namespace as for
>>> WebSockets?
>> I may be confused but I think the URLs only show up in the constructor
>> and thus would not apply over to the DataMediaStreamTrack.
> I'm reading this spec:
>
> http://dev.w3.org/html5/websockets/
>
> It shows:
>
> interface WebSocket : EventTarget {
> readonly attribute DOMString url;
> <----------------------------------------------- Here
>
> // ready state
> const unsigned short CONNECTING = 0;
> const unsigned short OPEN = 1;
> const unsigned short CLOSING = 2;
> const unsigned short CLOSED = 3;
> readonly attribute unsigned short readyState;
> readonly attribute unsigned long bufferedAmount;
>
> // networking
> [TreatNonCallableAsNull] attribute Function? onopen;
> [TreatNonCallableAsNull] attribute Function? onerror;
> [TreatNonCallableAsNull] attribute Function? onclose;
> readonly attribute DOMString extensions;
> readonly attribute DOMString protocol;
> void close([Clamp] optional unsigned short code, optional DOMString
> reason);
>
> // messaging
> [TreatNonCallableAsNull] attribute Function? onmessage;
> attribute DOMString binaryType;
> void send(DOMString data);
> void send(ArrayBuffer data);
> void send(Blob data);
> };
>
> There are lots of interesting fields here. If we inherit from that
> specification, each and every field must have a defined value, even if
> it is "always NULL", and each and every function must do something
> sensible, even if it is "throw an UNIMPLEMENTED" exception.
>
> That's the cost of using inheritance.
Yes. Right now, we have readyState, bufferedAmount, onopen, onclose,
onerror, onmessage, send, close and binaryType.
We do not have url, extensions, or protocol. So inheriting the
interface and extending it may be reasonable, if we have answers for
those. We do need (optional) additional functionality to access things
like sequence numbers for unreliable or unordered data, for example.
--
Randell Jesup
randell-ietf@jesup.org
Received on Tuesday, 10 April 2012 14:23:30 UTC