Subject: [hybi] Support for sub-protocols on the WebSocket API?

From: Clebert Suconic <[email-masked]>
Date: Tue, 6 Sep 2011 16:39:20 -0500

I was looking for a way to send a custom opcode on a subprotocol, but
the WebSocket API (at least the one I found in most browsers) only
provides three very basic methods for sending, and nothing where I
would be able to use on  sub-protocol specifics as defined on the
spec. I could only find ways to send payload from client to server.

Is there any other API where I could make use and still use it to
develop sub-protocols in javascript?

I was looking into defining a subprotocol in javascript and be able to
use it on any client where web-socket is supported.

Thanks,

---

From: John Tamplin <[email-masked]>
Date: Tue, 6 Sep 2011 17:42:13 -0400

On Tue, Sep 6, 2011 at 5:39 PM, Clebert Suconic
<[email-masked]>wrote:

> I was looking for a way to send a custom opcode on a subprotocol, ...
>

A subprotocol does not allow you to define new opcodes -- you can however,
define how those payloads are to be interpreted (ie, send everything as
OPCODE_BINARY, and then process it how you like).

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Clebert Suconic <[email-masked]>
Date: Fri, 9 Sep 2011 13:34:12 -0500

On Tue, Sep 6, 2011 at 4:42 PM, John Tamplin <[email-masked]> wrote:
> On Tue, Sep 6, 2011 at 5:39 PM, Clebert Suconic <[email-masked]>
> wrote:
>>

What about session 11.8 on the websocket-protocol:
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14#section-11.8

If I wanted to create an extension (a sub-protocol), I would be able
to use additional opcodes, right?

Or there's another interpretation here?

---

From: John Tamplin <[email-masked]>
Date: Fri, 9 Sep 2011 14:54:26 -0400

> Or there's another interpretation here?

An extension is not the same as a subprotocol -- extensions can define new
opcodes, subprotocols can't.  Think of subprotocols as a layer on top of
WebSockets.

You could define an extension and make it mandatory for your subprotocol.

---

From: Clebert Suconic <[email-masked]>
Date: Fri, 9 Sep 2011 14:07:58 -0500

Ok, if I make an extension... say through ietf by following the
process...  how can I use the opcodes?  Is there anything on the API I
could make use.. or I would have to change each clients to support my
extension? (say.. recompile the browser or where the opcode is being
implemented?)

On Fri, Sep 9, 2011 at 1:54 PM, John Tamplin <[email-masked]> wrote:
> On Fri, Sep 9, 2011 at 2:34 PM, Clebert Suconic <[email-masked]>
> wrote:
>>

-- 
Clebert Suconic
http://community.jboss.org/people/[email-masked]
http://clebertsuconic.blogspot.com

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 12 Sep 2011 12:34:02 +0900

On Sat, Sep 10, 2011 at 04:07, Clebert Suconic <[email-masked]>wrote:

> could make use..

No

> or I would have to change each clients to support my
Yes.

---

From: Clebert Suconic <[email-masked]>
Date: Sun, 11 Sep 2011 22:47:22 -0500

>> process...  how can I use the opcodes?  Is there anything on the API I

Wouldn't make sense to add support for it?

---

From: John Tamplin <[email-masked]>
Date: Sun, 11 Sep 2011 23:56:42 -0400

On Sun, Sep 11, 2011 at 11:47 PM, Clebert Suconic <[email-masked]

> Wouldn't make sense to add support for it?

What would JS need of different opcodes?  Why couldn't it do whatever it
wants inside a binary frame?

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 12 Sep 2011 13:18:01 +0900

On Mon, Sep 12, 2011 at 12:47, Clebert Suconic <[email-masked]>wrote:

> > On Sat, Sep 10, 2011 at 04:07, Clebert Suconic <
> [email-masked]>
> > wrote:
> >>

What kind of use case do you have in your mind? It looks like application
level opcode in the application data part is sufficient for your case. Use
the first byte of application data to switch processing for example.

Basically, I think, use of new opcode or reserved bit makes sense when the
feature you want to implement involves something JavaScript cannot do (or
not feasible). E.g. interaction with other tabs, use of something not
accessible from JavaScript, high performance processing by native code, etc.