- From: <bugzilla@jessica.w3.org>
- Date: Thu, 31 May 2012 05:50:45 +0000
- To: public-webapps@w3.org
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 UTC