On Mon, Aug 6, 2012 at 3:28 PM, Jonas Sicking <jo...@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