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