On Fri, Dec 2, 2011 at 1:07 PM, Glenn Maynard <gl...@zewt.org> wrote:
> On Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart <vand...@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
