Re: [websockets] Getting WebSockets API to Last Call

On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> We're keen to resolve the remaining issues with the WebSockets API and have a timetable
> to get to Candidate Recommendation. From informal conversations we've had, we believe
> other browser vendors share this goal. I think the current WebSocket API is feature
> complete and meets the requirements for publishing a Last Call working draft to
> encourage wider review and feedback. There are no tracker issues for WebSockets. Here
> is my analysis of the outstanding bugs (not closed, where resolution not Fixed).
> I believe the outstanding issues could be resolved as Last Call comments and would like
> to see a CfC to publish a LCWD shortly.

Yes, we'd like to see this happen very soon too as we'd like to
unprefix our implementation.

> 9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put normative
> requirements in parenthesis
> Resolved, NeedsInfo
> MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and
> from an anonymous contributor

Sounds good.

> 10213 - The definition of "absolute url" makes https:foo not an absolute url
> Open, Assigned to Adam Barth
> MICROSOFT PROPOSAL: Section 3 of the protocol spec
> (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the
> valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address
> supplied does not match this format.

I don't have an opinion on url parsing since I don't know enough about
it. However throwing an exception on an invalid URI sounds good to me.

> 12180 - give the name of url to download the Jetty server
> Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago
> MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations

Agreed.

> 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise
> they're ambiguous
> Reopened, Assigned to Ian Hickson
> MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call

Agreed.

> 12816 - Make second argument in constructor an object for future extensibility
> Resolved, WontFix
> MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future
> extensibility but to allow binaryType to be set now.

I'd like to see this change made too.

So far there's been two counter proposals in the bug for how to deal
with future extensions (which I strongly suspect we'll end up having
to do in the future):
1. Wait to open the connection until returning to the event loop which
delays starting the already slow network handshake. This is especially
a problem in Web Workers where returning to the event loop can take a
very long time.
2. Make the second argument either be a string, a array of strings, or
a object. This is messy both from a user perspective and from an
implementation perspective.

Do any implementations prefer the current specced behavior? Otherwise
I'll push for making this change in firefox.

> 12917 - "deflate-stream" should be an optional extension when establishing a connection
> Resolved, WontFix
> MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec
> on what is optional in the protocol. The API spec should not normatively mention specific
> extensions. References to "deflate-stream" should be informative and only provided as examples.

I agree with the WONTFIX here. I think optional parts of
specifications is a bad thing in the web space and bad for
interoperability. If we really end up needing the ability to set
optional parts we can always add that in the future.

> 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong();
> //allow client to receive response of ping
> Open, Assigned to Ian Hickson
> MICROSOFT PROPOSAL: We don't think this is necessary.

Agreed. If needed we can always add this in the future.

> 13162 - The notes really do need to be cleaned up to be made explicit.
> Open, Assigned to Ian Hickson
> MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call

Agreed.

> 13178 - binaryType should be immutable after connection is established
> Open, Assigned to Ian Hickson
> MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.

I don't agree with making binaryType immutable, and I added a comment
to that effect to the bug. I did also put in another proposal in the
bug which also aims to reduce implementation complexity and improve
performance.

> 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results
> in an error event, should be more clearly specified
> Open, Assigned to Ian Hickson
> MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.

Agreed.

/ Jonas

Received on Thursday, 7 July 2011 22:56:09 UTC