Re: [hybi] Subprotocol and Control Frames

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Tue, Oct 4, 2011 at 10:36 PM, Hapner mark <[e-mail]> wrote:

>  >From: John Tamplin [[e-mail]]
>  >Sent: Tuesday, October 04, 2011 9:18 PM
>  >To: Hapner mark
>  >Cc: Greg Wilkins; [e-mail]
>  >Subject: Re: [hybi] Subprotocol and Control Frames
>  >
>  >On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark <[e-mail]>
> wrote:
>  >Thanks for the further clarifications/corrections ...
>  >
>  >So if I understand correctly, extension opcodes are globally defined and
> extensions are required to be defined such that they can be combined in
> adhoc combinations.
>  >
>  >They are globally defined, but it is yet to be determined whether they
> can be allocated in overlapping fashion or dynamically.  We couldn't reach
> agreement on those, so we left it the way it is now, which basically means
> they can't be used without getting some agreement on them.  For example, one
> proposal was that each extension specify how many opcodes and reserved bits
> it needs, and those are allocated as needed per connection.  If we go with
> that approach, we could create a spec that defines the mechanism for
> dynamically allocating these resources, and then extension specs that want
> to make use of this could simply refer to that spec.
>  >
>  >Basically, the intent is to cross that bridge when we get there, and
> hopefully we will have real use cases to consider to guide that decision.
>  >
>  >I would disagree that most users of HTTP put a framing protocol in HTTP
> bodies. They put MIME types (i.e. content types) in bodies. Content types do
> not contain protocol control - only the HTTP header contains (should
> contain) protocol control.
>  >
>  >Most JSON or SOAP-based services I have used do in fact have some sort of
> message type in the payload, but YMMV.
>  >
>  >To be specific, providing one extension control frame opcode for
> overloaded use by a subprotocol, combined with allowing subprotocols to use
> extension data (or append 'subprotocol extension data' to the end of
> protocol extension data) would likely resolve this issue (MBWS would
> definitely use it). Also, the API would need to be extended to provide
> access to these subprotocol features so AJAX clients could access them.
>  >
>  >I really don't see the difference -- if MBWS were to say "I want 20 bytes
> of extension data", how is that any different than just using the first 20
> bytes of the WS payload as its extension data, and the remainder of the WS
> payload as the upper-level payload?
>
> My main issue is with putting MBWS control frames into WebSocket message
> payloads.
>
> Putting MBWS message metadata into its associated message payload is a
> lesser issue. It requires the definition of an extension data mechanism
> within text message payloads and binary message payloads that mirrors what
> already exists in WebSocket.
>
> You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of
> us is fully correct.
>
> HTTP added a framing protocol over TCP so does WebSocket. If all extended
> use of WebSocket has to treat it like TCP, then Clebert and I should get on
> with implementing our MBWS message framing protocol and stop annoying the
> WG.
>
> On the other hand, there is great potential to reuse/extend the WebSocket
> protocol in much the same way that the web community has with HTTP. If the
> community had treated HTTP like it was TCP it would be worse off (as WS* did
> and is). Possibly the TCP analogy with WebSocket is not the most productive
> mental model of WebSocket's role in web architecture.
>
> What would be the harm in considering extending the functionality of
> WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less
> layer be a useful result.


At the end of the day, the way I think of it is that extensions are for
protocol level things that the client and server software must support.
subprotocols are contracts between the application software running in the
client and server, but the client and server are blissfully unaware of any
of these semantics. It would be hell if you had to recompile Apache to
understand the semantics of each website you wanted to serve.

If you're changing the framing in a meaningful way (e.g. changing message
opcodes), then servers and intermediaries need to be altered and recompiled
to deal with those changes. At that point, you've defined an extension. If
you're not meaningfully changing the framing, but you're simply instructing
the other endpoint "Here's how to interpret the data contained in the
payload of the message", the servers and intermediaries don't need to be
recompiled and you are defining a subprotocol.

I suspect that what you are trying to do, like many things, could be written
as either an extension or a subprotocol. We could define an extension for
google search - send a search opcode and the search terms and get back a
results opcode with the search results. Yes, it's a bit of a facetious
example, but I'm merely trying to illustrate a point. The mere fact that
something can be done that way doesn't make it necessarily appropriate or
desirable. It's not clear to me as a browser vendor why I would want to
implement either a google search extension or an MBWS extension, for
example, nor why I would want to agree to opcodes and reserved bits being
allocated for its use.

-Ian