On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song <jungkee.song@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.