Re: [hybi] Framing take IV

[Ian Hickson <[e-mail]>]

On Thu, 5 Aug 2010, Greg Wilkins wrote:
> 
> the thing that stops people defining subprotocols is that the concept of 
> a subprotocol is entirely undefined.
> 
> Currently it is exposed in the js API as a simple string.  There is no 
> indication how that string can be used, how capabilities can be 
> discovered, declared or negotiated.  There is no mechanism to allocate 
> op-codes in the first byte other than to come here and try to convince 
> you that my extension is a good idea.
> 
> If we can clearly define an extension and/or subprotocol mechanism then 
> I think we would be able to answer the concerns of those that feel the 
> need for particular features but see no way of achieving them in the 
> current protocol.

I'm not sure I follow. A subprotocol wouldn't use "opcodes".

HTTP is a subprotocol for TCP, as is SSH, FTP, or IMAP. They all just use 
TCP as two streams of bytes (one in each direction).

Similarly, you can have subprotocols on WebSockets. They all would just 
use WebSockets as two queues of events (one in each direction).

What do we need to do to indicate how this can be used? There's no 
limitation to how it can be used. Are you saying you think the WebSockets 
spec should include protocol design advice?

Is there an equivalent for Comet-style protocols? (That is, subprotocols 
that use HTTP as the transport?)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'