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 [2] with 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." [3] 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 [1], 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 [4] 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.

would seem natural to me do to something like this:

    interface Blob {
      DOMString getURN(in DOMString mediaType,
           [Optional] in DOMString contentDisposition,
           [Optional] in DOMString name);

Given that a File that one gets from the user will still tell you its
name and detected mediaType, and can have a constant urn, there seems
to be no conflict in leaving the File interface as-is and adding
something like getURN to Blob.  On the off chance that you want to
override the detected mediaType for a file, force a contentDisposition
of attachment, or change the name, you might still use getURN there as

To be clear: you want the File object's URN capabilities to inherit from Blob, and not be separate, correct? Thus, each Blob has an affiliated URN, and when a Blob is a File, it uses the Blob's getURN method?

Can you explain what a "contentDisposition" is a bit better? Can you write some psuedo-code showing how contentDisposition is used, perhaps to flesh out the above use cases?

-- A*




Reply via email to