Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 11:31 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> > At TPAC [1,2] I described our proposal for adding an isReusable flag to
> > createObjectURL. A common pattern we have seen is the need for a blob URL
> > for a single use (for example, loading into an <img> element) and then
> > revoking the URL. This requires a fair amount of boilerplate code to
> > handle the load/error events.
> >
> > createObjectURL is modified as follows:
> >
> > static DOMString createObjectURL(Blob blob, [optional] bool isReusable);
> >
> > The value of isReusable defaults to true if it is not supplied and this
> > results in the behaviour documented for File API today. However, if you
> > supply false for the flag then the first dereference of the URL revokes
> it.
> >
> > This means that you can do something like:
> >
> > imgElement.src = URL.createObjectURL(blob,false)
> >
> > and not worry about having to call URL.revokeObjectURL to release the
> Blob.
> >
> > We have implemented this in experimental form in IE10 preview builds and
> > it works well. There seemed to be a fair amount of support at TPAC and
> we're
> > hoping this will be adopted in the File API spec.
> >
> > Thanks,
> >
> > Adrian.
> >
> > [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02
> > [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
>
> I object to adding boolean flag arguments to any new APIs.  They're a
> blight on the platform.  Further, baking non-essential arguments into
> the argument list almost guarantees confusion down the line when
> *more* options are added.
>
> Please add this as an options object with a "reusable" property, like
> "createObjectURL(blob, {reusable:false})" (or whatever name gets
> decided on, like "single-use").
>
> ~TJ
>

I completely agree.  Boolean traps are a serious problem for intuitiveness
and hamstrings the ability to add more options later that don't further
confuse the situation.

Received on Wednesday, 14 December 2011 17:11:25 UTC