Re: Proposed new text for noaccess

I am fine with either of these.

ISTR we suggested that AddStream() should have an error callback.
We could use that.

-Ekr



On Sat, Oct 26, 2013 at 3:25 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> 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.
>
>
>