hi Spencer, Toerless,
To address this point in particular:
I can not believe that WebSockets is seen as a bad but unavoidable
protocol approach. I rather think a lot of APP area folks in the IETF
would state exactly the opposite: It is a pretty good coalescion of
higher layer needed functionality (during conn setup), fits snugly into
the web centric app layer framework (browsers, http), and manages to minimize
messy network layer midpoint problems (eg: flow state problems in midpoints).
And WebSocket effectively is also meant to kill a lot of the protocols
that where really badly built on top of HTTP, aka: it solves a lot more
BCP 56 problems than that negatives of BCP 56 apply to it.
Absolutely. However, it's constrained to run atop TCP, which means that as an
application you have no control over the _transport_ characteristics of a
WebSockets connection. You get SOCK_STREAM, end of discussion, with whatever
global parameters your kernel has decided are good for you.
That's the situation we're looking to improve.
And +1 to "thanks, Toerless, for the comments". Hope to see you at the charter
discussion on Monday.
Cheers,
Brian