- From: Adam Bergkvist via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Sep 2016 12:53:28 +0000
- To: public-media-capture-logs@w3.org
Thanks @a2sheppy for reviewing this text carefully. Your interpretation that the two first algorithms are intended for when a script adds or removes a track is not entirely correct in all cases. These algorithms are just sets of tasks with no given context. It's true that the addTrack() function and the MediaStream() constructor use the 'add a track' steps, but so does the algorithm below (step 2) where the context is a track being added by some event initiated by the User Agent (and not the script). So it's the caller that sets the context. One option to make the situation clearer would be to remove the 'add a track' and 'remove a track' altogether and inline the two steps that actually do something in the callers algorithms. It would be less jumping around when reading the text with the only drawback that if we would like to add more steps, we would have to do that in several locations. But that's not very likely and I believe that we ended up with fewer steps in these algorithms than we expected to begin with. We would also get rid of the strange step "If the operation in the previous step was aborted prematurely, then abort these steps." which is used by the two 'Initiated by UA' algorithms. `"A new MediaStreamTrack has been added to this stream. Note that this event is not fired when the script directly modifies the tracks of a MediaStream ."` Is the below better? `"A new MediaStreamTrack has been added to this stream. Note that this event is not fired when the script modifies the tracks of a MediaStream via some API call."` -- GitHub Notification of comment by adam-be Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/388#issuecomment-246671462 using your GitHub account
Received on Tuesday, 13 September 2016 12:53:35 UTC