- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 27 Oct 2013 00:25:11 +0200
- To: public-media-capture@w3.org
On 10/26/2013 10:44 PM, Martin Thomson wrote: > On 26 October 2013 08:35, Eric Rescorla <ekr@rtfm.com> wrote: >> "If any tracks in a MediaStream added via AddStream() have a noaccess >> constraint, >> the implementation MUST throw an exception of XXX" (I am still a little >> vague on >> how we have decided to do exceptions. > I'm not sure about this part. If you think about the scenarios in > which this is used, an application might want to initiate negotiation > prior to receiving consent. Chucking exceptions all over the place is > going to be a bit of an impediment to that. How about this - and the > case where the peerIdentity constraint != the actual peer identity - > result in silence/black being sent, with some other way to learn about > this. The stats API seems to be the catchall here, but I always hope > for a better, cleaner answer than that. > I would actually prefer an error callback or an exception - the programmer made an error, the application should do something exceptional. If the programmer never checks the appropriate indicator, the first discovery of the error may be a customer call to a helpdesk saying "my camera can't send" or something like that. The programmer can always choose to ignore an error. (addStream already has one case where it throws an error - it throws InvalidStateError when the PC is closed - so making it throw one more isn't a revolution.) -- Surveillance is pervasive. Go Dark.
Received on Saturday, 26 October 2013 22:25:43 UTC