Subject: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 29 Mar 2012 07:32:03 +0000

Yes, it’s true that there are many APIs, however, from the point of view of the working group we are coordinating with only one of those.

From our charter:
    The group will continue coordinating with the W3C WepApps working
    group with respect to the above deliverables and to ensure the best
    match possible between the WebSocket protocol and the WebSocket API.

This doesn’t preclude about informal discussion regarding other APIs, but the only one the WG should lose sleep over is the above as it’s in our charter. Right now the question is relevant with respect to the W3C WebApps WebSocket API, because that working group is undergoing rechartering, so if any further change is needed to the above it behooves us to make that clear shortly.

So far, it seems like we’re fine without additional requirements on that API.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Arman Djusupov
Sent: Thursday, 29 March, 2012 09:07
To: 'John Tamplin'
Cc: [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

The JS API is just one of the APIs that uses the WebSocket protocol, there are already multiple Java, .NET, Mono, Python  etc. client and server libraries available for Windows, Android, iOS etc. These obviously have their own APIs that do not depend on browser functionality. It doesn’t really matter what is supported by a particular API, it is fine if that API supports a subset of the functionality. A little back JS didn’t support binary data, but that didn't mean that we shouldn't have introduced binary frames. If the JS API cannot support some specific functionality then let it not, but this functionality should be available to other platforms.

With respect, I don’t agree that we should look at any WebSocket related specs using only “Chrome to Google server pool” point of view.

With best regards,
Arman

From: John Tamplin [mailto:[email-masked]]
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
If anybody feels strongly that there is any API impact of either the mux or compression, please support such claims.

I think there should not be at this point, in either one -- which means that I think exposing the existing of MUX channels (including being able to open multiple at a time) should be off the table at this point.

In the long term, I suspect we may want to alter the API to let the application have better control over compression, but I don't think we want to do that until we have more experience about exactly what is useful.

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

---

From: "Alexander Philippou" <[email-masked]>
Date: Thu, 29 Mar 2012 12:02:43 +0300

Hi Gabriel, can you please clarify for me the new charter, does it mean that we intend to move away from the original charter which stated that:

Wide browser support is a goal for the bidirectional communication mechanism, however the solution should also be suitable for clients other than Web Browsers

The Working Group will work to standardize a generic solution that can work efficiently in as many of the deployed environments as possible and in particular in all the elements of the web infrastructure (e.g. web browser, generic HTTP client, HTTP server and HTTP-aware intermediaries like proxies, load balancers, caches, etc.) and it is not specific for just one.

Alexander

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Thursday 29 March 2012 10:32
To: Arman Djusupov; 'John Tamplin'
Cc: [email-masked]
Subject: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)

With best regards,

Arman

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

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 29 Mar 2012 11:08:07 +0000

I’m assuming you’re looking at the old charter as found here:

http://tools.ietf.org/wg/hybi/charters?item=charter-hybi-2011-04-28.txt

These are orthogonal. What you point out is the guideline for the *protocol* development. There is no difference there.  What you left out of your quote is in the paragraph previous to the one you quote:

  In particular, the working group has liaised with the W3C WebApps
  working group around the WebSockets protocol and the need to support
  the WebSocket API;

No difference: protocol work is general. API coordination is with W3C WebApps.

From: Alexander Philippou [mailto:[email-masked]]
Sent: Thursday, 29 March, 2012 11:03
To: Gabriel Montenegro; 'Arman Djusupov'; 'John Tamplin'
Cc: [email-masked]
Subject: RE: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)

Alexander

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Gabriel Montenegro
Sent: Thursday 29 March 2012 10:32
To: Arman Djusupov; 'John Tamplin'
Cc: [email-masked]<mailto:[email-masked]>
Subject: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)

From our charter:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Arman Djusupov
Sent: Thursday, 29 March, 2012 09:07
To: 'John Tamplin'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [hybi] MUC: channel ID semantics

With best regards,
Arman

From: John Tamplin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; [email-masked]<mailto:[email-masked]>
Subject: Re: [hybi] MUC: channel ID semantics