Re: Lazy Blob

On Mon, Aug 6, 2012 at 3:28 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Arthur was awesome enough to dig it up:
>

Thanks.



> <http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html>
> <http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm>
>
> Though we would need to modify that proposal such that .response
> returns a stream also in the OPENED state as long as the "send() flag"
> is set.
>

This is actually very different, I think.  Looking at the Stream proposal,
it looks like calling client.send() actually kicks off a fetch, just as
with any other XHR responseType, and then the Stream object you get from
client.response represents the data coming in from that fetch.  (I may be
misinterpreting this; section 10 is written as a delta spec, which makes it
a bit hard to follow.)

URLObject doesn't represent a fetch; it represents the data required to
perform a fetch.  This means that you don't need to perform a fetch at all
in order to create the URLObject.  (For example, if you're creating a
playlist of 10000 songs in a Song Manager app and you want to hand those
off to a Song Player app via an intent, you don't want to perform 10000
fetches to create those objects, not even HEAD requests.)  A fetch only
occurs if the URLObject is actually used, and also importantly, you can
reuse the URLObject in as many fetches as you want and get the same data
(eg. play a song multiple times).  In other words, a URLObject works just
like a URL, except with some metadata attached (headers, credentials) and
without exposing the actual URL to the receiver.

It's not exactly clear to me what happens, in the Stream proposal, if (in
the second example in the introduction) you assign a URL pointing to
theStream to multiple objects.  Do the receivers of the URL just start
receiving data at whatever point the stream is at at the time (which would
break most protocols)?  With URLObject, this simply results in two fetches.

Also, Streams aren't seekable.  (That would require a major overhaul of
StreamBuilder to support.  I think I remember discussing this at one point:
you'd need a pull interface--"give me 1000 bytes at position 10"--rather
than a push interface.  I think I discarded that idea since the particular
sequence of fetch callbacks would be impractical to specify.)  URLObject
would allow media seeking, if they point at a video or audio stream, since
they represent a resource rather than a fetch.

-- 
Glenn Maynard