Re: [File API] Other sources for Blob data.
On Fri, Dec 2, 2011 at 6:14 PM, Steve VanDeBogart wrote: > 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. > Hmm. Full interoperability might be difficult, though. For example, different browsers might request ranges for media resources in different ways; one browser might read the first 1K of a file first while another might read the first 4K. That's probably impossible to specify tightly in general. I'd be able to live with that, but others might object. 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. > I wouldn't worry much about MediaObject as a use case; it's just a poorly designed API. File should be a property on MediaObject, not its base class. -- Glenn Maynard
Re: [File API] Other sources for Blob data.
On Fri, Dec 2, 2011 at 1:07 PM, Glenn Maynard wrote: > On Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart 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
Re: [File API] Other sources for Blob data.
On Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart 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
Re: [File API] Other sources for Blob data.
On Thu, Dec 1, 2011 at 8:58 AM, Glenn Maynard wrote: > On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart wrote: > >> In several thought experiments using the File API I've wanted to create a >> Blob for data that I haven't materialized. It seems that a way to create a >> blob backed by an arbitrary data source would be useful. In particular, I >> would like to see a blob constructor that takes a URL and size as well as >> one that takes a callback. >> >> A URL constructed blob could use a byte range request when a FileReader >> requests a slice of the blob. i.e the internal implementation could be >> reasonably efficient. >> > > Note that since Blobs need to know their size when constructed, > constructing a blob like this would need to be async. > > That would also imply that if you read a whole file this way, you're > always going to make two HTTP requests; a HEAD to determine the size and > then a GET. > This is why I suggested the constructor take a URL and a size, since you might already know it. Though I guess with an async constructor the size could be optional and if it isn't present a HEAD request could determine it. > A callback backed blob would be a bit more complicated. Maybe something >> like the interface below, though you'd probably need another level of >> indirection in order to deal with concurrency. >> >> interface BlobDataProvider : EventTarget { >> void getDataSlice(long long start, long long end); >> void abort(); >> >> readonly attribute any result; >>readonly attribute unsigned short readyState; >> >> attribute [TreatNonCallableAsNull] Function? onloadstart; >> attribute [TreatNonCallableAsNull] Function? onprogress; >> attribute [TreatNonCallableAsNull] Function? onload; >> attribute [TreatNonCallableAsNull] Function? onabort; >> attribute [TreatNonCallableAsNull] Function? onerror; >> attribute [TreatNonCallableAsNull] Function? onloadend; >> } >> > > FYI: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029998.html > > FWIW, I was thinking along these lines: > > 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. > interface BlobDataProviderResult : EventTarget { > void result(any data); > void error(); > attribute [TreatNonCallableAsNull] Function? onabort; > } > > result can be called multiple times, to provide data incrementally. > Progress events are up to the browser. > > That said, the only use case I've seen for it is weak DRM, which isn't > very interesting. 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 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. -- Steve
Re: [File API] Other sources for Blob data.
On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart wrote: > In several thought experiments using the File API I've wanted to create a > Blob for data that I haven't materialized. It seems that a way to create a > blob backed by an arbitrary data source would be useful. In particular, I > would like to see a blob constructor that takes a URL and size as well as > one that takes a callback. > > A URL constructed blob could use a byte range request when a FileReader > requests a slice of the blob. i.e the internal implementation could be > reasonably efficient. > Note that since Blobs need to know their size when constructed, constructing a blob like this would need to be async. That would also imply that if you read a whole file this way, you're always going to make two HTTP requests; a HEAD to determine the size and then a GET. A callback backed blob would be a bit more complicated. Maybe something > like the interface below, though you'd probably need another level of > indirection in order to deal with concurrency. > > interface BlobDataProvider : EventTarget { > void getDataSlice(long long start, long long end); > void abort(); > > readonly attribute any result; >readonly attribute unsigned short readyState; > > attribute [TreatNonCallableAsNull] Function? onloadstart; > attribute [TreatNonCallableAsNull] Function? onprogress; > attribute [TreatNonCallableAsNull] Function? onload; > attribute [TreatNonCallableAsNull] Function? onabort; > attribute [TreatNonCallableAsNull] Function? onerror; > attribute [TreatNonCallableAsNull] Function? onloadend; > } > FYI: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029998.html FWIW, I was thinking along these lines: interface BlobDataProvider : EventTarget { void getSize(BlobDataProviderResult result); void getDataSlice(long long start, long long end, BlobDataProviderResult result); } interface BlobDataProviderResult : EventTarget { void result(any data); void error(); attribute [TreatNonCallableAsNull] Function? onabort; } result can be called multiple times, to provide data incrementally. Progress events are up to the browser. That said, the only use case I've seen for it is weak DRM, which isn't very interesting. -- Glenn Maynard
[File API] Other sources for Blob data.
In several thought experiments using the File API I've wanted to create a Blob for data that I haven't materialized. It seems that a way to create a blob backed by an arbitrary data source would be useful. In particular, I would like to see a blob constructor that takes a URL and size as well as one that takes a callback. A URL constructed blob could use a byte range request when a FileReader requests a slice of the blob. i.e the internal implementation could be reasonably efficient. A callback backed blob would be a bit more complicated. Maybe something like the interface below, though you'd probably need another level of indirection in order to deal with concurrency. interface BlobDataProvider : EventTarget { void getDataSlice(long long start, long long end); void abort(); readonly attribute any result; readonly attribute unsigned short readyState; attribute [TreatNonCallableAsNull] Function? onloadstart; attribute [TreatNonCallableAsNull] Function? onprogress; attribute [TreatNonCallableAsNull] Function? onload; attribute [TreatNonCallableAsNull] Function? onabort; attribute [TreatNonCallableAsNull] Function? onerror; attribute [TreatNonCallableAsNull] Function? onloadend; } Alternatively, exposing the (internal) interface FileReader uses to interact with a Blob would remove the magic from a Blob and let a user synthesize their own blob. -- Steve