On Thu, Dec 1, 2011 at 8:58 AM, Glenn Maynard <gl...@zewt.org> wrote:
> On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart <vand...@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
