- From: Glenn Adams <glenn@skynav.com>
- Date: Thu, 2 Aug 2012 00:23:43 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CACQ=j+eiD6ydhAstFvQTeVSrMnmO7TzBUUuvVdP7x=_bgc3oQg@mail.gmail.com>
On Wed, Aug 1, 2012 at 10:44 PM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 1 Aug 2012, Glenn Adams wrote: > > > > Of course, implementers are free to ignore whatever they want, but last > > time I checked, the W3C was a consensus based standards organization > > which means agreement needs to be reached on what specs go out the door > > and what are in those specs. > > Doesn't really matter what's in the specs going "out the door" if it's not > what's implemented... > > I don't really care about the XHR side of this (happy to let Anne figure > that out), but since WebSockets was mentioned: what's the use case that > involves Web Socket? I don't really understand what problem we're trying > to solve here. > based on the pattern proposed by partial interface BlobBuilder { Blob getBlobFromURL (XMLHttpRequest xhr); }; i would like to support two use cases: (1) simple - single blob send, single blob response (2) multiple - multiple instances of simple, i.e., send/response pairs these could be handled with the following: partial interface BlobBuilder { // simple Blob getBlobFromSource (WebSocket ws, Blob send); // multiple Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler); }; in the simple case, the creator of the lazy blob provides the initial send blob, which is sent by the underlying lazy blob implementation upon a read on the lazy blob, then the next (and only) response blob is returned as a result from the read in the multiple case, the creator of the lazy blob provides an event handler to invoke to send a blob corresponding to a read on the lazy blob, thus providing for multiple send/receive blob message pairs, with one lazy blob for each pair of course, the simple case could be folded into the multiple case, leaving only one method to define: partial interface BlobBuilder { Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler); }; a use of this might be as follows: var bb = new BlobBuilder(); var ws = new WebSocket("ws://example.com:9999/test"); var lb = []; ws.onopen = function() { lb.push ( bb.getBlobFromSource(ws, function() { ws.send(getSendMessageAsBlob(1)); }) ); lb.push ( bb.getBlobFromSource(ws, function() { ws.send(getSendMessageAsBlob(2)); }) ); lb.push ( bb.getBlobFromSource(ws, function() { ws.send(getSendMessageAsBlob(3)); }) ); setTimeout(sendAndReceive); } function getSendMessageAsBlob(msgNum) { return new Blob ( [ String(msgNum) ] ); } function sendAndReceive() { var numMsgs = 0; var numBytes = 0; // trigger read on queued lazy blobs while ( lb.length > 0 ) { b = lb.shift(); // read on size triggers stored send 'promise' numBytes += b.size; numMsgs += 1; } alert('Received ' + numMsgs + ' messages, containing ' + numBytes + ' bytes.'); ws.close(); } of course, this example make use of a particular message paradigm (send/recv pairs); while this may capture only a subset of interchange patterns, one could easily generalize the above to provide more flexibility;
Received on Thursday, 2 August 2012 06:24:33 UTC