[NUT-devel] Some sanity...

[Rich Felker]

On Wed, Feb 06, 2008 at 11:25:45AM +0100, Nico Sabbi wrote:
> On Wednesday 06 February 2008 11:11:50 Luca Barbato wrote:
> > Rich Felker wrote:
> > > I think we need a reality check here, as NUT is a FROZEN spec.
> >
> > Ok
> >
> > > This whole broadcast issue has brought up a lot of "new
> > > requirements" with no legitimate argument for how they fulfill
> > > any need that NUT does not already meet. "Because MPEG does it"
> > > is NOT A REASON!!
> 
> the matter is reversed: MPEG works that way for a reason, although

MPEG works that way for lack of good design. There's total
codec-container-transport incest --- wow that makes 3 generations!
The MPEG folks never had any interest in making things universal and
codec-agnostic or application-agnostic. Their only aim was being able
to make closed-box consumer-oriented applications capable of
delivering the audio and video packets to decoder chips.

NUT's philosophy is that the container should not dictate what you can
or can't do with it; it's up to the recipient of the data, not the
author, to decide whether they want to use it in simple playback,
efficient nonlinear editing (within the limitations of the codec
used), streaming to others, piping between unix-style tools, etc.

As part of this, I agree that the container should not artificially
preclude broadcast applications even though we do not anticipate any
adoption by broadcast folks. But I believe the existing NUT design
covers the requirements of broadcast, especially timing, in full.

> > We could make it an addendum, have the broadcast stuff kept in
> > compatible mode and just first help me converting the current nut
> > in rfc (I don't have much time lately so help IS needed) and start
> > pushing it there.
> 
> addendums, extension and spec specializations are the recipe for
> disaster, whatever direction NUT chooses. A unified NUT spec
> encompassing *from the very start* everything needed is the only
> sane way to proceed, IMO

I mostly agree, though I would rather see useless things in an
addendum that no one bothers with than polluting the core spec.
Throwing premature design at a problem without understanding whether
there really is a problem to be solved, especially when that design is
influenced by such a design atrocity as MPEG, is even more of a recipe
for disaster.

Rich