On Wed, Jun 12, 2013 at 5:58 PM, Adam Bergkvist <adam.bergkvist@ericsson.com > wrote: > On 2013-06-12 00:04, Robert O'Callahan wrote: > >> I think it's helpful to have a permanent "ended" state. For example, an >> application might handle "ended" (or "inactive") the way Youtube does, >> and change state to display different UI. It's unexpected and confusing >> if the stream can suddenly revive again underneath, and would likely >> lead to application bugs. >> > > I don't really see these issues if active/inactive is documented properly. > > The media elements can be played again after they end. Yes but only if the application itself calls play() In which case it's not unexpected. If a stream can leave its last state, then I think renaming that state to > active-something, as Jim proposes, makes sense. I agree. If the last state is final, then I think we should keep it as ended. But in > that case, what's the state of a stream created with no args to the > constructor? It seems like we need a "new" state to represent this since we > can't use ended == true here. It possible to figure out the "new" state > right now, but it's not as obvious as the other states. > What I proposed above is that a stream transitions to the "ended" state when it has no active tracks but did at some point in the past. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Wednesday, 12 June 2013 06:05:31 UTC