Message info
 
To:Arman Djusupov From:Gabriel Montenegro Subject:[hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics) 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: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Arman Djusupov
Sent: Thursday, 29 March, 2012 09:07
To: 'John Tamplin'
Cc: hybi@ietf.org
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:jat@google.com]
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

 

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> 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