Hi Greg,
On Aug 7, 2009, at 10:07 PM, Greg Wilkins wrote:
Again this is valuable feedback.
That's three -0' or -1's on the look-a-like-HTTP approach.
I'll ponder what sort of simplifications could be made
if the HTTP style is dropped.
I'm not sure the HTTP-style framing is necessarily a minus, it's just
not much of a plus. I think the complexity cost is from the number of
features added. I think a possible fruitful approach might be:
- Review what features BWTP adds.
- Pare down to just the most essential ones that provide a lot of
benefit at the protocol level relative to doing them at the
application level.
- Leave enough extensibility that other useful protocol-level features
can be added in a future version.
I'm concerned about the 1.0 version of the protocol, whatever it may
be, being too complex. The downsides of complexity are: (a) longer
time-to-market for the core functionality; (b) likely worse
interoperability in the initial implementations; (c) more risk of
security bugs. On the other hand, I would also be concerned about
deploying something that didn't have an elegant path to future
extension.
I intend to look over the protocol details and I will encourage the
other folks doing implementation or design work on WebKit's WebSocket
to give it a look. Then hopefully I can add a more concrete proposal.
I tentatively agree with Jonas that in-protocol multiplexing sounds
like one of the most valuable additional features, as compared to
WebSocket Protocol.
Regards,
Maciej
