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

RE: Lazy Blob

From: Jungkee Song <jungkee.song@samsung.com>
Date: Wed, 08 Aug 2012 09:53:24 +0900
To: 'Robin Berjon' <robin@berjon.com>, 'Glenn Maynard' <glenn@zewt.org>
Cc: 'WebApps WG' <public-webapps@w3.org>, 'Anne van Kesteren' <annevk@annevk.nl>, 'Arun Ranganathan' <arun@mozilla.com>, 'Jonas Sicking' <jonas@sicking.cc>
Message-id: <001501cd7500$39e9b600$adbd2200$%song@samsung.com>
> > - 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).
> +1 from me on this one.


> I get a sense that this could possibly be a consensus position (or at
> least I'm going to claim that it is so as to get disagreement to
> Assuming it is, the next steps are:
> . Having agreed on a solution, do we agree on the problem? (i.e. would
> this get implemented?)
> . If so, we can bake this as a standalone delta spec but it would make
> more sense to me to make the changes directly to the relevant specs,
> namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought?
> In either case, I'm happy to provide the content.

Having hammered out a consensus, I would like to contribute to providing the


Jungkee Song
Samsung Electronics
Received on Wednesday, 8 August 2012 00:53:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC