- 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