W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 2 Aug 2012 00:23:43 -0600
Message-ID: <CACQ=j+eiD6ydhAstFvQTeVSrMnmO7TzBUUuvVdP7x=_bgc3oQg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WebApps WG <public-webapps@w3.org>
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 GMT

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