Re: createBlobURL

On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman <michaeln@google.com> wrote:
> Chrome currently has this as...
>         DOMString createBlobURL(in Blob blob);
>         void revokeBlobURL(in DOMString blobURL);
> ... no prefix... on both Window and WorkerContext.
> An important aspect of placing these interfaces on the Window and
> WorkerContext was to scope the lifetime of the manufactured url to the
> respective window or worker object.  I thought adam's url api was all about
> parsing and building valid urls, so i'm not sure these methods are such a
> good fit for that interface.

I agree. Another thing that is nice about the window.*BlobURL() API is
that it makes it clear which origin the created url will have. I.e.
the origin of the window which it's called on.

We could maintain that even if we used a URL constructor by saying
that it's tied to the window whose .URL property was used as
constructor, but it makes it a much more indirect connection.

> Renaming to createObjectURL/revokeObjectURL seems like the most
> straightforward way to generify the existing methods.

I talked with Arun about this, and one argument was that we can keep
the createBlobURL name since the returned url always uses the scheme
'blob'. However I have to say that I really like the
createObjectURL/revokeObjectURL names, and it might create less
confusion.

So createObjectURL/revokeObjectURL has my vote.

/ Jonas

> On Mon, Oct 18, 2010 at 11:50 AM, Arun Ranganathan <arun@mozilla.com> wrote:
>>
>>  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*
>> [1]
>> https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing
>>
>
>

Received on Tuesday, 19 October 2010 00:31:39 UTC