On Tue, Nov 17, 2009 at 6:25 PM, Arun Ranganathan <a...@mozilla.com> wrote: > Eric, > > >> I recall you saying at TPAC that you wanted to keep the Blob >> interface as small as possible, since it seemed likely to get used in >> a lot of places. I think that's an excellent goal, but of course, >> having said that, I am immediately going to suggest that you add >> something to it. >> > > > I'm definitely not averse to additions :) Actually, I'm also following the > discussion initiated by Maciej about BinaryData  with > public-script-co...@w3.org. Eventually, I believe ECMAScript will provide a > Binary primitive (perhaps ByteArray), and I think Blob should expose that > primitive. This would be a natural extension of what I envision Blob to be > used for. I also envision natural streaming extensions to this API. > >> How would you feel about exposing a way to produce a URN from a >> Blob, instead of just getting one from a File? > > I'm not averse to it. In fact, it was originally in the Blob interface > (which at that time, was dubbed "FileData"). We moved it to the "File" > interface since the understanding of use cases at the time was that " all > URL consumers expect a full file."  You've provided use cases that show > that this isn't the case, and so we should revisit our earlier > understanding. More on your use cases below: > >> This seems likely to >> have wide-ranging uses. Pretty much anywhere you have a blob of data, >> you might want to hand it off to the browser, even if it didn't come >> from, or wasn't, a single user-supplied file. Here are a few use >> cases, but I'm sure more won't be hard to come up with: >> >> * Viewing a single chapter of a book in a frame. >> * Slicing one episode out of a DVD and handing it to the video tag, so >> that the player controls start and end at the episode boundaries. >> * Analogous to the game-asset archive I mentioned at , one might >> pack a number of small files together to speed download [using only >> HTTP compression], then parse them apart on the client. Picture a >> Picasa client written in the web browser; it's got to handle maybe >> 10000+ thumbnails, and putting each in a separate file would be >> terribly inefficient. Pulling down a tarfile would be a lot quicker. >> >> > > I can understand why you'd want *partial* data exposed through a URL, and > why your API may "force" a type on the partial data. Question: would a > fragment identifier scheme  address any of these use cases, or is this > completely orthogonal to the use cases you envision? I ask because you > envision a "chapter within a frame" but I'm not sure what the frame data > structure is.