Re: [websockets] ArrayBuffer added back to the ED

2012-07-26 Thread Takashi Toyoshima
Hi,

Thank you for handling this topic.
I support this change [r1.272] is applied to v1 spec.

On Thu, Jul 26, 2012 at 5:01 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Hi All,

 Earlier today, Hixie added ArrayBuffer back to the WebSocket API ED (see
 [r1.272]) as requested in bug [17263] which ATM is Resolved/WontFix.

 Since the CfC to move this spec to CR passed on July 18 (but the CR has not
 yet been published), I would appreciate it you would please Raise Your Hand
 if you support this fix for v1.

 If there is consensus for this fix to be included in v1, it would mean the
 next step on the REC track would be to return the spec to LCWD.

 -Thanks, AB

 [r1.272]
 http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.271;r2=1.272;f=h
 [17263] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263






Re: WebSocket API clise Method

2012-02-02 Thread Takashi Toyoshima
Hi Bronislav,

On Tue, Jan 31, 2012 at 11:09 PM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
 Hello,
 based on this bug
 http://code.google.com/p/chromium/issues/detail?id=93609
 referencing
 http://dev.w3.org/html5/websockets/#dom-websocket-close

 Looking in WebSocket protocol close codes definitions
 http://tools.ietf.org/html/rfc6455#section-7.4.1

 I wonder about codes

 1003 indicates that an endpoint is terminating the connection
      because it has received a type of data it cannot accept (e.g., an
      endpoint that understands only text data MAY send this if it
      receives a binary message).

 1008 indicates that an endpoint is terminating the connection
      because it has received a message that violates its policy.  This
      is a generic status code that can be returned when there is no
      other more suitable status code (e.g., 1003 or 1009) or if there
      is a need to hide specific details about the policy.

 1009 indicates that an endpoint is terminating the connection
      because it has received a message that is too big for it to
      process.


 Those are/maybe application level codes (generic one). E.g. your WS
 implementation supports

To my understanding, these codes are used by browser and server layer.
For example, 1003 may mean the browser doesn't support binary type frames
in its WebSocket protocol stack.

Meaning of application level binary support will depend on application level
subprotocols. You may want to define application level close code in
the range 3000 to 4999 to notify that client doesn't support some
kinds of features.
Or you can define some feature negotiating frameworks over your subprotocols.

Application level error code could be useful for server side
application handler.
In this case, it doesn't matter if the server side protocol stack
itself understand
these application level codes.

 both text and binary types (in browser), but your application expects only
 text messages (1003).
 Client (application) expects first message from server to contain specific
 information, but server fails to provide (1008).
 Client (application) have requested certain data, e.g. part of a file, but
 data received from server are bigger than requested.

 Application level codes (3000-4999) does not apply here, because in my
 previous examples shows, that server
 simply did not understand the application protocol in a first place, so it
 makes no sense for client to send
 application level close codes to server - those codes would have no meaning
 there.


 Brona