- From: Rich Tibbett <richt@opera.com>
- Date: Wed, 30 May 2012 18:09:44 +0200
- To: public-webapps <public-webapps@w3.org>
Hi, Right now we call window.URL.createObjectURL to obtain a Blob URI. As a developer I'd like Blob URI creation functions to hang off the Blob interface directly making things a bit simpler and more intuitive. It seems like we could be far less verbose in Blob URI creation by making a Blob.url method that would return a new, unique, one-time only Blob URI at all times. That means we won't have long-lived Blob URIs living in a document and developers won't need to call revokeObjectURL on Blob URIs obtained in this way. The first time any resulting Blob URI is dereferenced then user agents would automatically revoke the associated Blob URI, preventing reuse elsewhere. If the web app needed a new Blob URI to use elsewhere they would call Blob.url again to obtain a new, unique, one-time only Blob URI. It's not obvious that we should let Blob URIs hang around indefinitely or make developers responsible for calling revokeObjectURL manually. Since the creation of a Blob URI seems to have relatively little overhead, it seems reasonable that we could create a new Blob URI each time .url is called. I wrote a quick Blob.url shim that should help to demonstrate this proposal: http://jsfiddle.net/MV233/ The same addition would apply for MediaStream (i.e. MediaStream.url) though the spec says createObjectURL only takes a Blob object at the moment (which seems wrong but that is what I'm working to). This API method could alternatively be called .getURL or .createURL. The method does return dynamic content and it does seem to act more like a method than an attribute so that would make sense IMO. At best this would be a replacement for window.URL.createObjectURL. At worst, it's a convenient shortcut for developers to creating and using no-nonsense Blob URIs. -- Rich Tibbett Opera Software ASA
Received on Wednesday, 30 May 2012 16:10:18 UTC