Re: MediaStreams and src attributes

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.

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". 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?

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.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]