Re: [File API] Other sources for Blob data.
On Thu, Dec 1, 2011 at 8:58 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart vand...@google.comwrote:
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 Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart vand...@google.comwrote:
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 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.comwrote:
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 6:14 PM, Steve VanDeBogart vand...@google.comwrote: 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
[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
Re: [File API] Other sources for Blob data.
On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart vand...@google.comwrote:
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
