James Almer (12023-09-26):
> We don't want you to resign anything. We want a proper discussion in how to
> handle SDR, if at all. Pushing it in a form that everyone agrees is not
> ready for upstream is not a good idea.

We can agree on this, if we consider that the opinion on whether it is
ready of people who have made it clear they will never consider it
“ready” is to be disregarded, just as much as somebody who says “nak” to
a patch without reasons.

> SDR is big, so its API needs to be designed carefully and in an extensible
> way.
> libavradio must absolutely not be libavdevice redux, and it must have its
> own, versatile and extensible API that a lavd device can then work with,
> even if not using its full potential, because libavradio can have other
> users that will not be constrained to what lavf/lavd can do.

SDR **will be** big. SDR **will need** to have its own versatile and
extensible API.

But the way to get there is to start small. First make it a module, with
a very simple API to the rest. Then, as it grows, it acquires utility
functions: an internal API that we can change as we discover what it
needs. And progressively the API stabilizes and becomes good.

Nothing successful starts as a library. Suggesting that a project starts
as a library is either an expression of incompetence or a dishonest
attempt at killing it.

Regards,

-- 
  Nicolas George