[whatwg] createObjectURL(stream) protocol issue

On 08/13/11 01:48, Darin Fisher wrote:
> Putting implementation details aside, I agree that it is a bit unfortunate
> to refer to a stream as a blob.  So far, blobs have always referred to
> static, fixed-size things.
>
> This function was originally named createBlobURL, but it was renamed
> createObjectURL precisely because we imagined it being useful to pass things
> that were not blobs to it.  It seems reasonable that passing a Foo object to
> createObjectURL might mint a different URL type than what we would mint for
> a Bar object.
>
> It could also be the case that using blob: for referring to Blobs was
> unfortunate.  Maybe we do not really need separate URL schemes for static,
> fixed size things and streams.
Back in ancient history (late 90s, I think), when I wrote the first 
version of stuff that eventually merged into RFC 4395, "New URI 
schemes", I thought the set of operations an URI supported was pretty 
important.

In fact the text of RFC 4395 says:

2.4.  Definition of Operations

    As part of the definition of how a URI identifies a resource, a URI
    scheme definition SHOULD define the applicable set of operations that
    may be performed on a resource using the URI as its identifier.  A
    model for this is HTTP; an HTTP resource can be operated on by GET,
    POST, PUT, and a number of other operations available through the
    HTTP protocol.  The URI scheme definition should describe all
    well-defined operations on the URI identifier, and what they are
    supposed to do.

    Some URI schemes don't fit into the "information access" paradigm of
    URIs.  For example, "telnet" provides location information for
    initiating a bi-directional data stream to a remote host; the only
    operation defined is to initiate the connection.  In any case, the
    operations appropriate for a URI scheme should be documented.

    Note: It is perfectly valid to say that "no operation apart from GET
    is defined for this URI".  It is also valid to say that "there's only
    one operation defined for this URI, and it's not very GET-like".  The
    important point is that what is defined on this scheme is described.

So if that consideration is still of concern, the next question is of 
course "are there operations that make sense for a stream that don't 
make sense for (current uses of) blob:, or vice versa"?

If "blob:" was intended to mean "reference to internal object, hand it 
to APIs, the APIs will tell you if they don't like them", that 
consideration may not be that important.

> Hmm...
> -Darin
>
>
>
> On Thu, Aug 11, 2011 at 2:13 AM, Tommy Widenflycht (?????)<
> tommyw at google.com>  wrote:
>
>> Would it be possible to give the associated URL for a mediastream to have
>> its own protocol, for example mediastream:, instead of the proposed blob:?
>>
>> window . URL . createObjectURL(stream)
>> Mints a Blob URL to refer to the given MediaStream.
>>
>>
>> This would tremendously help the implementation.
>>
>> Thanks in advance,
>> Tommy
>>
>>
>> --
>> Tommy Widenflycht, Senior Software Engineer
>> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
>> Org. nr. 556656-6880
>> And yes, I have to include the above in every outgoing email according to
>> EU
>> law.
>>

Received on Monday, 15 August 2011 06:54:25 UTC