1,295
edits
Talk:MediaStreamAPI: Difference between revisions
→Graph cycles
No edit summary |
|||
| Line 47: | Line 47: | ||
Blocking all the streams involved in a cycle until the cycle is removed seems like an undesirable behavior. It will mean that in cases where a bug introduces a cycle in a dynamically-constructed graph, the end user simply gets no audio, or worse, part of the audio he expects is missing but the rest is playing. This will make it easy for these sorts of bugs to slip by, and make it difficult to debug them. I would argue that forming a cycle should throw an error immediately so that the point where the cycle is formed can be found easily, and a developer can then walk back and examine the graph to understand why he has formed a cycle. | Blocking all the streams involved in a cycle until the cycle is removed seems like an undesirable behavior. It will mean that in cases where a bug introduces a cycle in a dynamically-constructed graph, the end user simply gets no audio, or worse, part of the audio he expects is missing but the rest is playing. This will make it easy for these sorts of bugs to slip by, and make it difficult to debug them. I would argue that forming a cycle should throw an error immediately so that the point where the cycle is formed can be found easily, and a developer can then walk back and examine the graph to understand why he has formed a cycle. | ||
[[User:KevinGadd|kael]] | [[User:KevinGadd|kael]] | ||
''roc: I think you're right, for the cases where the cycle is created due to an API call. Depending on how things evolve there might be cases where we can't detect at the time of an API call that a cycle will be created, and in that case we would have to block instead.'' | |||
== Miscellany == | == Miscellany == | ||