W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

[File API] Other sources for Blob data.

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

Received on Thursday, 1 December 2011 09:34:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC