Re: [hybi] Informal survey: "Non Request-Response Communication over the Web, and What's Missing"

Some commentary ...

Be careful with "reliable data delivery".
This has many different meanings to different people.

Bayeux and Cometd (for example) have acknowledgement extensions
specifically for unreliable data networks (mobile) that allow the server or
client to know if the opposite side has received the complete message or
not.

This level of reliable message delivery could probably exist as a WebSocket
extension. a message-ack extension with exposure at the various WebSocket
APIs.

WebSocket Gaps:

1. Half-Closed

half-closed connections are currently supported by the WebSocket protocol
spec.
and many existing implementations do it correctly today (thanks autobahn!)
several libraries already rely on this behavior (bayeux, cometd)

however, other layers, apis, and non-websocket bugs can cause problems here.
eg: its impossible with Android 5.x to do half-closed via SSL, on any
protocol, mostly due to many horrid bugs in their SSLEngine.

2. Flow-Control

For standard http/1.1 (not http/2) this is handled at the tcp/ip level.
For http/2 this is handled by its flow-control parts of that spec.
What else do you mean here?
Is this section about how to expose this on the Javascript WebSocket API?

3. Message-level metadata

Let this be part of an application specific protocol layer, or an extension
handling it (with Javascript WebSocket API changes to expose extension
manipulation. see below)
Note: This is quite a passionate topic on the ietf-http-wg mailing list
also, with more people against it than for it.

4. Keep-Alive

Most existing applications are happy with a combination of tcp/ip
keep-alive and websocket ping/pong so far.
With http/2 there's other keep-alive strategies.
Is is really a WebSocket protocol gap?
Or just another Javascript WebSocket API gap?

5. Multiplexing and session priority

One concern with the common response: WebSocket over HTTP/2 will address
this.
It seems that the folks running the http2 spec track (ietf-http-wg) have
punted and want hybi to define it, and the folks here at hybi seem to think
that the ietf-http-wg folks will define it.  Have there been some
discussion between these 2 groups yet? (even offline / face to face?)

The Layering Concern:

Don't forget, the websocket extensions are a layer too.

Other thoughts:

If this is an effort to get baseline of effort for the Javascript WebSocket
in the browser, then you also have the following often asked questions ...

* Handling authentication / authorization credentials.  submitting them,
and getting reasonable error messages out of the API for when problems
occur.
* Controlling extensions, both at the initial handshake, and ongoing in the
write/send apis (think compress / dont compress flags as a real world
usecase for today)
* Better error messages when use of the API results in failure to
open/connect due to violation of WebSocket spec rules

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Fri, Jan 16, 2015 at 1:42 AM, Takeshi Yoshino <tyoshino@google.com>
wrote:

> Hi all,
>
> I and Wenbo did an informal survey of protocol gaps. We hope this would
> help moving forward the discussions about protocol/API design to some
> extent.
>
>
> https://github.com/bidiweb/bidiweb-semantics/blob/master/SurveyOfProtocolGaps.md
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>