W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [File API] Other sources for Blob data.

From: Steve VanDeBogart <vandebo@google.com>
Date: Fri, 2 Dec 2011 11:20:01 -0800
Message-ID: <CA+9kOWN_AN9vcVr0iXmm9P5eH7ZS1FEf0X8dJAgHJk26X9niVQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps <public-webapps@w3.org>, Tony Payne <tpayne@google.com>
On Thu, Dec 1, 2011 at 8:58 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart <vandebo@google.com>wrote:
>> In several thought experiments using the File API I've wanted to create a
>> Blob for data that I haven't materialized.  It seems that a way to create a
>> blob backed by an arbitrary data source would be useful.  In particular, I
>> would like to see a blob constructor that takes a URL and size as well as
>> one that takes a callback.
>> A URL constructed blob could use a byte range request when a FileReader
>> requests a slice of the blob.  i.e the internal implementation could be
>> reasonably efficient.
> Note that since Blobs need to know their size when constructed,
> constructing a blob like this would need to be async.
> That would also imply that if you read a whole file this way, you're
> always going to make two HTTP requests; a HEAD to determine the size and
> then a GET.

This is why I suggested the constructor take a URL and a size, since you
might already know it.  Though I guess with an async constructor the size
could be optional and if it isn't present a HEAD request could determine it.

> A callback backed blob would be a bit more complicated.  Maybe something
>> like the interface below, though you'd probably need another level of
>> indirection in order to deal with concurrency.
>> interface BlobDataProvider : EventTarget {
>>   void getDataSlice(long long start, long long end);
>>   void abort();
>>   readonly attribute any result;
>>    readonly attribute unsigned short readyState;
>>   attribute [TreatNonCallableAsNull] Function? onloadstart;
>>   attribute [TreatNonCallableAsNull] Function? onprogress;
>>   attribute [TreatNonCallableAsNull] Function? onload;
>>   attribute [TreatNonCallableAsNull] Function? onabort;
>>   attribute [TreatNonCallableAsNull] Function? onerror;
>>   attribute [TreatNonCallableAsNull] Function? onloadend;
>> }
> FYI:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029998.html
> FWIW, I was thinking along these lines:
> interface BlobDataProvider : EventTarget {
>   void getSize(BlobDataProviderResult result);
>   void getDataSlice(long long start, long long end, BlobDataProviderResult
> result);
> }

As you say, since the size is an attribute of the blob, I don't see the
benefit to making it part of the callback... I guess unless you're trying
to support the streaming blob case.  But maybe that's just an argument for
making it
an async function instead of an attribute in the Blob interface.

> interface BlobDataProviderResult : EventTarget {
>   void result(any data);
>   void error();
>   attribute [TreatNonCallableAsNull] Function? onabort;
> }
> result can be called multiple times, to provide data incrementally.
> Progress events are up to the browser.
> That said, the only use case I've seen for it is weak DRM, which isn't
> very interesting.

The use case I've been thinking about is getting metadata out of files.  So
I may want to examine a slice at the beginning of a file and then,look at
other slices at the end or various places in the middle.  For a local file,
not a problem, but if you want to integrate an online file provider, (drop
box or something else of that ilk), you can either use a file/callback
based blob, or build a second interface to accessing file data into your
webapp.  It all feels cleaner and nicer if just a single interface can be

It seems you've been following this issue longer than I, do you know of a
bug filed against the File API for something like this?  If not, I'll
probably file one.

Received on Friday, 2 December 2011 19:20:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC