Re: MediaStreams and src attributes

On 8/22/12 4:58 PM, Adam Barth wrote:
> The important thing to me is that we don't break the reflection
> semantics of the src property.  On that point we appear to agree.

That's a good argument for not doing what we're currently doing. 
However, as roc has already mentioned, using a URI is also not a great 
solution not only because of lifetime issues but also because of what a 
URI means. Streams are tied to a particular page by default, so taking a 
URI and using it in another page should not work.

Option (B) seems reasonable to me, as long as we can settle on a good name.

-Anant

> On Wed, Aug 22, 2012 at 4:51 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Thu, Aug 23, 2012 at 11:35 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>
>>>> 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.
>>
>>
>> OK, although if we can't come up with a good name for something that usually
>> indicates a problem with the 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.
>>
>>
>> And lifetime problems. It may be valuable to have a dedicated API that
>> covers exactly the resources we have JS object representations for; I think
>> that's as general as we can get without introducing the lifetime problems.
>>
>>> 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.
>>
>>
>> We can't do it that way. For example you should be able to set the source of
>> a media element to a Blob and then seek within it, but you can't seek within
>> a MediaStream.
>>
>>>
>>> It looks like HTMLMediaElement
>>> already has a "stream" property, which should perhaps be renamed to
>>> outputStream.
>>
>>
>> Yes, although that's not implemented in Gecko and we probably don't want it
>> after all anyway.
>>
>> 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]

Received on Friday, 24 August 2012 07:39:47 UTC