W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2012

Re: Proposal for API for Data

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 10 Apr 2012 10:19:09 -0400
Message-ID: <4F84415D.2080007@jesup.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 April 2012 14:23:31 GMT