Re: [Bug 19594] remove "BLOB" from url usage for createObjectURL()

On 21 August 2013 10:23, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Yeah, I thought that odd too.  I can see why you might say "at least once", but
>> I would have thought it straightforward enough to use the same URL as many
>> times as the platform can handle, as long as the stream remains valid.
>
> The problem with that formulation is that it contains a couple of
> undefined terms:
>
> - "as many times as the platform can handle" - how does an app developer
> know that number? The "at least once" formulation was intended to allow
> more than one, but that the developer could depend on there being at
> least one.

Fact is, it's always going to be some time between 0 and another
number that is probably less than infinity, and some number of uses
between 0 and a number less than infinity.

Stuff breaks.  The browser is going to have to do what it can to
ensure that the URL is usable as long as possible, but some forms of
breakage are out of anyone's control.

> - "as long as the stream remains valid" - how does an app developer test
> if an URL refers to a valid stream?

That's easy, though we can't do that right now.

var ms = new MediaStream(mediaStreamUrl);

> I'm fond of mandating the minimum guarantees we need in order to make
> sure it's useful. What is available beyond that might not be useful to
> standardize.

No guarantees are possible.  In practice, this isn't likely to be an
issue, but stuff does break.

>>> But you have to be careful with the wording because using srcObject
>>> has different implications for the lifetime of the stream than using
>>> createObjectURL.
>> I lost you.  The two ways of doing essentially the same thing have different
>> properties?  In what way?
>>
> Could we mandate that the two have the same effect (including creating a
> reference to the MediaStream object, which prevents garbage collecting)
> if the CreateObjectURL and <video>.src assignment happen in the same
> Javascript block?

Thanks to Anne pointing to the blob spec, I know understand that
URL.createObjectURL() creates a hard pin on the object that it
identifies, making that object immune to garbage collection until the
window (or iframe) is closed or the script explicitly releases that
pin.

That's a truly ugly property to create and then rely on, but I also
understand that this is what people wanted in order to transfer that
reference to other contexts (and maybe back again).  (As opposed to
just making the object itself transferable, but that seems to be a
gecko-specific concept, see [1].)

> I think Javascript gc is only supposed to happen, conceptually, between
> blocks.

Unless you want to change the way that createObjectURL works for
MediaStreams such that it is a weak reference, this is not relevant.
BTW, I'm totally OK with making the output a weak reference, such that
if the referenced MediaStream happens to be garbage collected, the
reference breaks (i.e., network error).  It does make it a little
trickier to pass a MediaStream reference between frames, but I think
that I'm totally OK with that.

[1] https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage

Received on Wednesday, 21 August 2013 17:39:41 UTC