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

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

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.

--
Steve