Re: MediaStreams and src attributes

On Wed, Aug 22, 2012 at 4:02 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Aug 23, 2012 at 5:25 AM, Adam Barth <w3c@adambarth.com> wrote:
>> 2) In working with web developers, I've often found that many people
>> do not have a clear conceptual model of the difference between
>> reflection properties and DOM attributes.  They use the two
>> interchangeably and don't really conceptualize them as separate
>> concepts.  I take that to be a success of the reflection mechanism: it
>> works so seamlessly that folks don't need to worry about it.  Breaking
>> the reflection semantics in this case will confuse and frustrate these
>> developers because they won't understand why assigning to the src
>> property works but setting the src attribute does not.
>
> So you're suggesting that people will try to do element.setAttribute("src",
> mediaStream) and wonder why it doesn't work. I'm not sure why they'd do
> that, since it's significantly more verbose than "element.src =
> mediaStream", but I'll take your point.

The point is that they should work the same because authors thing of
them as doing the same thing.

>> If you agree with me that we shouldn't break the reflection semantics
>> of the src attribute, there appear to be at least two alternatives:
>>
>> A) Instead of breaking the src property, we can introduce a new
>> property, for example "stream", with the type MediaStream.  Rather
>> than assigning to the src property, developers would instead assign to
>> the stream property, which would not have reflection semantics.
>
> I prefer this. We'd have to define what happens when both "stream" and "src"
> are set, but I guess that's not a big deal.
>
> I wouldn't call it "stream" though since media elements should be able to
> both consume and produce streams, so "stream" is ambiguous. I suggest
> "srcStream".

We can worry about the naming issues once we've settled on a design.

> Though, what if we want to support direct assignment of Blobs
> too? Would we add "srcBlob", or should we go to "srcObject"? Would having
> both "src" and "srcObject" confuse developers?

This thought process leads to you wanting to build the most general
thing, which is to be able to represent these resources using URLs.
That gives you the full matrix of producers and consumers.

If you want to stop short of the whole matrix, an sourceStream
property would seem to make sense, presuming you can create a
MediaStream object from a Blob.  It looks like HTMLMediaElement
already has a "stream" property, which should perhaps be renamed to
outputStream.

>> B) We can serialize the MediaStream into a DOMString so that it can be
>> reflected into the src attribute.  As discussed previously, we
>> wouldn't want this serialization to be implicit because we want to
>> help developers avoid resource leaks.  The natural approach here is to
>> use createObjectURL to explicitly serialize the MediaStream into a
>> URL, which can then be assigned to the src property and reflected into
>> the src attribute.
>
> Yeah. We should support this as well, but it's clumsy and forces the
> developer to grapple with lifetime issues.

Indeed.

Adam

Received on Wednesday, 22 August 2012 23:36:52 UTC