Subject: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics)

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 29 Mar 2012 09:34:57 +0200

Not the issue discussed in the f2f meeting, but I'm sure that introduction
of extensions we're now working on impacts extensions attribute of the
WebSocket API.

1. the API must define in what form it exports _Extensions In Use_. What to
include (just token? parameters together?), formatting, etc.

2. under use of the multiplexing extension, Sec-WebSocket-Extensions header
will contain both extensions applied to physical channel and logical
channels. We must figure out what should be exported from this mixture and
which side should do such transformation if any by coordinating with
webapps WG.

Takeshi

On Wed, Mar 28, 2012 at 17:50, Gabriel Montenegro <
[email-masked]> wrote:

>  Just a note that the API issues were discussed in the f2f today. If
> there are any such issues (and during the meeting it did not seem to be the
> case), the WG will coordinate with the W3C webapps WG, which is the
> organization we liaise with.****
>
> ** **
>
> As it turns out, they’re in the process of rechartering:****
>
> Web Applications Working Group:****
>
> http://www.w3.org/2012/03/webapps-proposed-charter.html****
>
> ** **
>
> If anybody feels strongly that there is any API impact of either the mux
> or compression, please support such claims. ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *John Tamplin
> *Sent:* Wednesday, 28 March, 2012 16:37
>
> *To:* Arman Djusupov
> *Cc:* [email-masked]
> *Subject:* Re: [hybi] MUC: channel ID semantics****
>
>  ** **
>
> On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov <[email-masked]> wrote:
> ****
>
> I would also like to suggest that we make it possible for an entire set of
> channels to be established together during/after the physical channel
> handshake. This would speed up the creation of logical channels for all
> types of clients.****
>
>  ****
>
> There are various options how to perform this.****
>
>  ****
>
> a) Include the request for the set of channels into the physical channel
> handshake.****
>
>  ****
>
> b) Use a more advanced format for the AddChannel request. For example it
> could specify the number of channels to create using the same handshake, so
> that a single handshake results in creating a range of identical logical
> channels.****
>
>  ****
>
> c) When the application needs to create multiple channels with different
> settings (e.g. protocol, compression and so on), it should be able to send
> a batch of AddChannel requests at once and then wait for each of those
> channels to be confirmed by the server.****
>
> ** **
>
> Again, this requires changes to the JS API, which isn't the purview of
> hybi but rather WHATWG.  With the current JS API, you can only create one
> channel at a time, so the only opportunity for bundling AddChannels
> together would be if another tab creates a channel at exactly the same time
> (or you delay the first request long enough to wait for another one). ****
>
> ** **
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google****
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: John Tamplin <[email-masked]>
Date: Thu, 29 Mar 2012 11:56:12 -0400

On Thu, Mar 29, 2012 at 3:34 AM, Takeshi Yoshino <[email-masked]>wrote:

> 1. the API must define in what form it exports _Extensions In Use_. What
> to include (just token? parameters together?), formatting, etc.
>

Ah, I wasn't aware they added that.  Making WeSocket.extensions be a
DOMString seems like a poor idea, as you now have to encode the list of
extensions (possibly with their parameters) into a string, and the JS will
have to decode it.  It seems making it return a list of objects with
defined properties would be much better.

> 2. under use of the multiplexing extension, Sec-WebSocket-Extensions
> header will contain both extensions applied to physical channel and logical

Since the WebSocket object in the browser may be a physical or logical
channel and applications shouldn't know the difference, it seems to me that
the extensions have to be that of the logical channel in the mux case.

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