- 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