- From: Steve VanDeBogart <vandebo@google.com>
- Date: Tue, 29 Nov 2011 13:09:19 -0800
- To: public-webapps <public-webapps@w3.org>
- Cc: Tony Payne <tpayne@google.com>
- Message-ID: <CA+9kOWMc0jVEpzhmfHQXTJgZ2MMgXPazVkcndGWd5SCiOeV=Rw@mail.gmail.com>
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
Received on Thursday, 1 December 2011 09:34:17 UTC