W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 7 Aug 2012 10:06:09 -0500
Message-ID: <CABirCh_0CFHuBHovA=JJj6fFPy6uiVCHUTMrwkNzcTv0rQVDew@mail.gmail.com>
To: Jungkee Song <jungkee.song@samsung.com>
Cc: WebApps WG <public-webapps@w3.org>, Robin Berjon <robin@berjon.com>
On Tue, Aug 7, 2012 at 4:07 AM, Jungkee Song <jungkee.song@samsung.com>wrote:

> window.intent.postResult(blob);
>
> From totally client developer's point of view, who perhaps do not care the
> underlying details at all, it is absolutely transparent to use the obtained
> blob as they used to deal with. (no matter which type of data the blob
> contains)
>

If you go down the "nullable size" route, the client developers do have to
care: every piece of code that receives a Blob would have to test to make
sure that the code still works if size is null.

That said, if you want to go that way, you can make URLObject and Blob more
interchangeable to users: make FileReader accept "Blob or URLObject", so
you can use it to read from URLObject just like Blob.  Users will still
have to be wary of the lack of .size and .type, but there's no avoiding
that.  This has the major benefit of keeping Blob's semantics very clear,
as it doesn't make Blob.size itself nullable.

A different option, equivalent to users, is to make URLObject a base class
of Blob.  URLObject would replace Blob in methods like
FileReader.readAsDataURL, createObjectURL and all other places where
methods can work without knowing the size in advance.  It would have no
methods or attributes (at least at the start).  In other words,

- URLObject represents a resource that can be fetched, FileReader'd,
createObjectURL'd, and cloned, but without any knowledge of the contents
(no size attribute, no type attribute) and no slice() as URLObjects may not
be seekable.
- Blob extends URLObject, adding size, type, slice(), and the notion of
representing an immutable piece of data (URLObject might return different
data on different reads; Blob can not).

Aside from that, the previous URLObject approach is unchanged: creating
URLObject requires no network fetches.  This wouldn't change the behavior
of Blobs themselves in any way.

(I don't like listing multiple options.  The latter option above seems like
the better design.  I only listed the simpler option as its lower surface
area may make it easier to get traction with.)

-- 
Glenn Maynard
Received on Tuesday, 7 August 2012 15:06:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT