W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

[Bug 17262] New: send function should have async interface

From: <bugzilla@jessica.w3.org>
Date: Thu, 31 May 2012 05:50:45 +0000
To: public-webapps@w3.org
Message-ID: <bug-17262-2927@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262

           Summary: send function should have async interface
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: toyoshim@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org


Current spec provide synchronous send function to transmit Blob object.
On the other hand, blob causes I/O operations and must be handled in async
operations.

Our current choices are;
 1. Block JavaScript thread until the requested blob is read to internal buffer
and become safely reusable.
 2. Queue the requested blob as a reference internally, then return from send
operation immediately.

Choice 1 is seriously problematic from two viewpoints. One is blocking
JavaScript thread.
The other is that JavaScript can not send larger blob than internal buffer size
because it requires to
copy to internal buffer at once.

Choice 2 has another critical problem. JavaScript has no chance to know when
the queued blob can be
reusable. It means that JavaScript never modify the blob after passing to
WebSocket send operation.
Also, this choice makes bufferedAmount meaningless because limitation by
internal buffer never depends
buffer size.

Anyway, JavaScript has no way to queue the object to internal send buffer
safely whether they want to
send blob or others. Busy requests will result in _fail_ and its limit looks
vague to JavaScript.

My proposed change is like this.

<Plan A: Change a series of send interfaces>
void send(DOMString data, optional Function callback);
void send(ArrayBufferView data, optional Function callback);
void send(Blob data, optional Function callback);

<Plan B: Introduce another event handler>
[TreatNonCallableAsNull] attribute Function? onsendend;

SendEndEvent : Event {
  // TBD
  readonly attribute boolean wasClean;
  readonly attribute unsigned long long size;
  readonly Object object;
};

In both of my plan, the behavior in no callback (event handler) is compatible
to current one.
If callback is set, another send request before callback invokation results in
_fail_.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 31 May 2012 05:50:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT