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

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

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 2 Dec 2011 16:07:08 -0500
Message-ID: <CABirCh-ekFKK-KpV90Ek7yX0HW8Evq4k-Sr4bBRN5sFDq7vjgQ@mail.gmail.com>
To: Steve VanDeBogart <vandebo@google.com>
Cc: public-webapps <public-webapps@w3.org>, Tony Payne <tpayne@google.com>
On Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart <vandebo@google.com>wrote:

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

The getSize method could be removed here, and creating a blob this way
would be synchronous: Blob.fromProvider(myProvider, size, type).  (I should
have removed the EventTarget base from BlobDataProvider, too.)

I don't know if there's any API precedent for passing in a user-created
object like this.  (It's similar to WebIDL dictionaries, but I'm not sure
if that's meant for functions.)  Anyway, the interface isn't really needed:
Blob.fromReader(myGetDataSliceFunc, size, type).

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 feels like a natural thing to provide, but I don't know if the use cases
so far are really that compelling.

Dropbox-like services don't really need to use a callback API; the
Blob-from-URL interface would probably be enough for that.

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.

I don't know of anything beyond that earlier discussion.

As an aside, in a sense "Blob from URL" is a natural inverse operation to

Glenn Maynard
Received on Friday, 2 December 2011 21:07:37 UTC

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