W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: createBlobURL

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 18 Oct 2010 14:50:41 -0400
Message-ID: <4CBC9701.1030708@mozilla.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
  On 10/18/10 12:16 PM, Anne van Kesteren wrote:
> On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking <jonas@sicking.cc> 
> wrote:
>> I would be ok with moz prefixing, though it would be nice to try to
>> find a solution pretty quickly if all this is is a discussion about
>> finding an appropriate name for this function.
> Well, if people agree with me that the appropriate place would be the 
> URL object -- assuming for now we are going to get that -- it would be 
> more involved than just renaming.

Moving these features to the URL object is more complex, but may be 
desirable.  I'm not sure I can shoe horn that big an adjustment in time 
for the CfC (not least of all because there isn't a draft of the URL API 
I can refer to.  I suppose I could specify the object that Adam has 
started with in the File API draft, though).  Maybe more discussion is 
warranted at a venue like the TPAC.

However, the revocation capability is pretty essential.  So this is 
something we'd have to add to the URL API.  And, the URL API has to be 
robust enough for both Stream and Blob use cases.

Since Anne's suggestion is an important but late-breaking one, I'd 
propose tabling a CfC till the editor's draft accurately reflects 
consensus on what to do with URL generation and revocation for Blobs.  
Maybe one thing we can do with existing implementation trains is:

1. Use vendor prefixing for create* and revoke* according to some rules 
[1] (since underscores are rarely used in DOM APIs, we'd have 
window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really 
like to hear from the Chromium folks.  Darin?  Others?

2. Adding revoke* to Adam's URL *or* create more versatile APIs that are 
better named within window* that account for Stream *and* Blob.

A benefit *and* a drawback of reusing the URL object is that this would 
make Blob URLs and HTTP URLs within the same object.  It makes sense to 
revoke a Blob URL, but much less sense to revoke another URL.  The 
schemes are different, but they *do* behave pretty much similarly.

I'd like a bit more implementer feedback, especially since doing 2. 
would be a pretty late breaking change.  I'm in favor of the best 
solution, but hate late breaking changes.  Chrome folks?

-- A*
Received on Monday, 18 October 2010 18:51:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC