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 15:14:07 -0800
Message-ID: <CA+9kOWMYTzaQ4+htce+SbjZdmOXe9xHS7bMWDJ74Er29j_AwFA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps <public-webapps@w3.org>, Tony Payne <tpayne@google.com>
On Fri, Dec 2, 2011 at 1:07 PM, Glenn Maynard <glenn@zewt.org> wrote:

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

I haven't seen any other places where the javascript runtime satisfies a
request by calling a previously called function, but in this case it seems
like it could be done safely.

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

Indeed - the Blob-from-URL interface isn't as powerful, but it may be

Another use case to consider... I was looking at this API proposal:
http://dev.w3.org/2009/dap/gallery/#mediaobject Each media object is a file
(a blob).  If I wanted to provide a cloud-backed gallery, I'd need some way
to make MediaObjects for each image/song/video.  It'd be a real shame to
have to download an object just to provide a MediaObject, which the
consumer may or may not access.

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

I went to file a bug, but there doesn't seem to be a File API component to
file it against.  I'll bug someone about that.

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

Indeed, I hadn't noticed that.

Received on Friday, 2 December 2011 23:14:53 UTC

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