Message info
 
To:\'John Tamplin\' From:Arman Djusupov Subject:Re: [hybi] MUC: channel ID semantics Date:Thu, 29 Mar 2012 10:07:19 +0300
 

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