[NUT-devel] revisions for nut-english.txt?

[Rich Felker]

On Mon, Feb 04, 2008 at 10:24:27AM +0100, Nico Sabbi wrote:
> > > And as solution you suggest
> > > an additional protocol layer. Which is equivalent to double layer
> > > muxing. Which actually violates the spec ...
> >
> > Storing other containers inside NUT violates the spec. Transmitting
> > many NUT streams at once on a single physical link does not violate
> > the spec anymore than sending NUT over TCP or storing it
> > interleaved with other data on physical disk platters does.
> >
> 
> the intention is not to incest the container with the transport,

Regardless of the intent, that's what it is.

> but to 
> - store N streams in a single NUT multiplex
> - identify which of the N streams belong together (in what mpegts
> calls program: 1 video, 1+ audio etc) by means of some
> info packet.

It's easy to identify which ones belong together as a program: THEY
ALL DO! If they don't, then they don't belong in the same container.

> Requiring multiple NUT streams is simply not practical and 
> out of question in certain environments (e.g. broadcast channels) .

How so?

> Simply look at how difficult it can be receiving crappy rt*p streams
> that require more than 1 socket.

This is unrelated. For sockets, surely you would not want to send
unrelated, irrelevant-to-the-recipient data; it's just a waste of
bandwidth. Where the issue comes in is with broadcast channels over
unidirectional links where all recipients receive the same content and
the physical channel's bandwidth is large enough for multiple
programs. It's really the fault of the hardware and protocol layers
for not already partitioning such channels into multiple virtual
channels. If they were going to switch to NUT (which I don't see them
doing regardless of what idiotic tailored-to-their-broken-systems
features we bloat NUT up with) they could just as well add a proper
protocol layer for channel partitioning at the same time.

Rich