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

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

-- 
Glenn Maynard