Blob as URN was Re: [FileAPI] Latest Revision of Editor's Draft

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 [2] with 
public-script-coord@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." [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.

> it
> 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
> well.
>   

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*
> [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html\
>   

[2] 
http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html

[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0609.html

[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0587.html

Received on Wednesday, 18 November 2009 02:25:52 UTC