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

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
used.

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.

--
Steve