Re: Proposal for API for Data

> 
> interface WebSocket : EventTarget {
>  readonly attribute DOMString url; <----------------------------------------------- Here

Good point - presumably that would need to return a URL that represented the ice datapath in use. Agree this is not necessarily a good map but we will need some way of knowing what the address for the other end of the connections.


> 
>  // 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;

Of the above, it seems like we need pretty much all of them with the same semantics as websocksts. Are there some of these you think we don't need?

> 
>  // networking
>  [TreatNonCallableAsNull] attribute Function? onopen;
>  [TreatNonCallableAsNull] attribute Function? onerror;
>  [TreatNonCallableAsNull] attribute Function? onclose;

Again, any of the above you think we don't need?

>  readonly attribute DOMString extensions;
>  readonly attribute DOMString protocol;

Lets ignore the above two for now but I would not be surprised to see us end up with similar things for similar reasons. You know is once the  SPDY guys show up :-)


>  void close([Clamp] optional unsigned short code, optional DOMString reason);

Seems like we will end up with a close one way or another 

> 
>  // messaging
>  [TreatNonCallableAsNull] attribute Function? onmessage;
>           attribute DOMString binaryType;
>  void send(DOMString data);
>  void send(ArrayBuffer data);
>  void send(Blob data);

Again seems like we will choose to have all of theses. 

> };
> 
> 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.
> 

Totally agree, and if we don't inherit but define our own object, we need to re specify all the fields that are the same. So the questions is are things 90% common, or 10% common. Note the problem with re-specifying is not the work or text to do it - it is the fact that the specification always turn out to be close but not the same and over time they tend to diverge. 

So if just about all  the fields are the same, I think we should consider making our spec as a "copy by reference" of the websocket spec and then say what is changed. If we think most of the fields are not the same then we should make our spec by "cut and paste" of text from websockets. 

So lets break this down to two stages of questions - the first is how close are these things anyways - does the WebRTC Data need most the functionality of websockets or not? and if that comes back as very close, then we can address the second line of questions which is what I think Cary has been poking at which is along the lines of even if inheritance could easily be done, should it be done. To me that set of questions is more interesting. I'm not at all sure which way we should go on this but my feeling is we have not looked at any of it enough yet to know what the right decision is. 


> That's the cost of using inheritance.
> 
>                               Harald
> 
>

Received on Tuesday, 10 April 2012 14:11:55 UTC