On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song <jungkee.s...@samsung.com>wrote:
> > > - 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. > > +1. > > > > 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. > > Having hammered out a consensus, I would like to contribute to providing > the > content. I would suggest using a different name than "URLObject". I think that name will cause a lot of head scratching.