[whatwg] createObjectURL(stream) protocol issue
harald at alvestrand.no
Mon Aug 15 06:54:25 PDT 2011
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
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.
> 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 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
More information about the whatwg