Re: Issue 1858: the astonishing behavior of transceiver.stop

"If the SDP-related specs told you to jump off a bridge?"

I need to allocate some time to this before I have anything useful to say,
but with regards to concern about wasting time: updating the spec to ensure
all transceivers are updated accordingly and updating all implementations
such that stopping one transceivers (sometimes) means stopping multiple
transceivers, including updating the processing steps for the removal of
remote tracks and the firing of events (if previously processed; ignored if
not yet processed), and ensuring edge cases still works. I think there will
be a lot of complexity we haven't thought of; rejecting one m= section in
SRD() might imply we reject an m= section that has not even been processed
by the webrtc-pc layer yet, maybe we need to keep a list of rejected
m-sections to be ignored while iterating over them? Maybe not. Point is we
need to think about it. In some cases transceivers have been assigned, in
other cases they haven't yet. When to process, when to fire, when to ignore
a related m= section, and so on.
And let's not forget the lack of test coverage we have, we have to write
tests for all of this. Let's make sure we actually want all of these
behaviors. Testing everything is surprisingly difficult.

Not wasting editorial time might mean wasting implementation time and
developer confusion and distrust of the API design. I don't want
high-effort low-impact APIs from an implementor's standpoint.

Anyway that's my gut reaction, it might turn out not to be a big deal, but
supporting stop() also seems like not a big deal in terms of what we get
out of it. Let's make sure we actually want this.

On Sat, Jul 21, 2018 at 5:50 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 12. juli 2018 13:51, skrev Iñaki Baz Castillo:
> > On Thu, 12 Jul 2018 at 13:38, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> >>
> >> - "SDP has special semantics for port=0 on an M-line"
> >> - "We've got to figure out how to set that! Since m-lines are
> >> transceivers, transceiver.<something>. BTW, what does it mean?"
> >> - "It means that the m-line isn't used any more - people use it to stop
> >> things"
> >> - "OK, let's call it transceiver.stop() then".
> >
> > This is, literally, making an API not because it's useful but just to
> > conform to some strange SDP semantic rules.
> >
> > I hope brilliant minds here do not waste too much time in this useless
> stuff.
> >
>
> Since the transceiver is inherently an SDP construct, I am all in favor
> of defining its behavior as "do what the SDP-related specs say". Let's
> not waste time being creative here.
>
>
>