Re: [FileAPI] Latest Revision of Editor's Draft

Arun:

    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.
   How would you feel about exposing a way to produce a URN from a
Blob, instead of just getting one from a File?  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.

In order for the URN to be useful, it would have to have a mediaType
associated with it, and then there's content-disposition to think
about, which then wants a file name as well...boy, that's a lot of
baggage.  However, since these aren't really inherent properties of
the Blob, just of the way you want the browser to view the Blob, 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.

This is a pure addition to your spec, so I think we can discuss it in
parallel with the publication of the WD.  I don't want to suggest that
this slow anything else down.

      Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html

On Mon, Oct 26, 2009 at 4:24 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> The latest revision of the FileAPI editor's draft is available here:
>
> http://dev.w3.org/2006/webapi/FileAPI/
>
> These changes constitute a substantial reworking of the original API along
> the lines of the "Alternative File API" proposal [1].  There are also some
> additional changes that are worth pointing out explicitly:
>
> 1. This editor's draft now resides in a new location in CVS.  Essentially,
> previous repository names had "FileUpload" in them and were confusing, since
> the API in question had less to do with *uploading a file* than *reading* a
> file.  "FileAPI" is shorter and more intuitive (and better describes what
> we're doing).  Previous drafts are worth keeping as historical artifacts
> reflecting the decision making of the WG, and so now include a caveat on
> them pointing them to the draft above.
>
> 2. Interface names have changed (notably FileData --> Blob) since the
> underlying FileData interface had uses on the platform beyond a file read
> API.  "Blob" as an interface name was first introduced by a Google Gears
> API, which I cite as an informative reference.
>
> 3. The event model resembles that of XHR2, with a few differences.  Notably,
> the APIs differ in their use of the 'loadend' ProgressEvent.
>
> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in this
> version of the specification.
>
> I don't anticipate the event model will be controversial, having seen a fair
> amount of discussion on the listserv.  But I do anticipate feedback about
> 4., as well as the remaining editor's notes.
>
> Looking forward to discussion of this API on this listserv and at the
> upcoming TPAC :)
>
> -- A*
> [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
> [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0091.html
>
>

Received on Thursday, 5 November 2009 23:32:50 UTC