- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 7 Aug 2012 17:16:01 +0200
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Jungkee Song <jungkee.song@samsung.com>, WebApps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Arun Ranganathan <arun@mozilla.com>, Jonas Sicking <jonas@sicking.cc>
On Aug 7, 2012, at 17:06 , Glenn Maynard wrote: > 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). +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 manifest). 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. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 7 August 2012 15:16:30 UTC