Clarification of alternatives (Re: Poll for preferred API alternative)

Thanks, registering your opinion as alternative 2, and pulling the 
discussion into another thread.

On 08/30/2012 12:47 AM, Martin Thomson wrote:
> First, I need to confirm that this encompasses several of the issues
> that we raised.  Namely:
> a. Use of SDP
> b. Use of Offer/Answer as defined in RFC 3264 or otherwise.
> c. Architectural and structural concerns
Use of offer/answer as defined in RFC 3264 was not part of the poll.

The "architectural and structural concerns" is not part of the poll, 
since that's not an actionable item. Reasonable people can differ with 
regard to which of the alternative approaches will incur the greater 
tecnical debt in the short and long runs.

>
> It's not clear that these are as inseparable as you claim.  For
> example, Justin and I have explored removing SDP as an independent
> option.  Though if you were to fix architectural problems, it is a
> likely outcome that the other changes would be necessary.
>
> Though I see other alternatives, from the options provided my
> preference is for 2.
>
> It seems clear that there are enough remaining items missing from
> PeerConnection that the effort to address those gaps is going to be
> progressively more difficult.
>
> All the guidance in software engineering suggests that refactoring is
> often necessary.  Reluctance to do so has serious consequences on your
> ability to add future features.  We're already seeing these problems.
Reasonable people can differ on whether any given refactoring is an 
improvement or not.

One standard approach to making refactoring possible is also to hide 
internal interfaces as long as there's not a clear use case for exposing 
them. The MS approach exposes more lower layer interfaces, thus locking 
in a greater number of features to the presently proposed implementation 
strategy.
>
> The term of art is "technical debt".  In addition to amassing a small
> fortune of our own in a relatively short interval, we've also
> inherited the years of accumulated SDP technical debt.
>
> --Martin
>

Received on Thursday, 30 August 2012 06:01:10 UTC