[NUT-devel] Broadcasting nuts [PATCH]

[Rich Felker]

On Fri, Feb 08, 2008 at 09:04:49AM +0000, Måns Rullgård wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > I've not been around today to reply to your email but just want to let
> > you know I agree some things might not work as well as I had hoped,
> > though I'm not sure I agree with your claims about what happens in
> > this example either. I'd like to look into it more but if it turns out
> > we cannot meet your requirements for broadcast optimality with my
> > proposals I'll be willing to see what we can come up with to remedy
> > that. I have an idea in mind for storing clock sync/buffering data
> > which would be more flexible and less invasive than the proposals so
> 
> I'd hardly call Michael's proposal invasive.
> 
> > far, I think, but I'll wait to write about it til I'm not about to
> > fall asleep.
> 
> I'd sure like to hear what you have in mind.

My idea isn't about the semantics but about syntax. Previous proposals
have suggested adding syntactic elements to the syncpoint. I'd like to
suggest having clock-synch or buffer-synch data as its own stream in
the NUT file. IMO there are several advantages:

- The frequency of the buffer/clock hints is not tied to syncpoint
  frequency. They can occur more or less often, whatever is needed.

- There can be more than one stream of buffer/clock hints, e.g. so
  that a single master file can contain hints for more than one
  broadcast scheme.

- No changes are needed to the spec except for specifying something
  which was before entirely unspecified (new stream type).

- It does not consume the first reserved field of syncpoints, so that,
  if we find another thing to put in the reserved space of syncpoints
  in the future, non-broadcast files don't have to waste a zero-byte
  in every syncpoint to be able to use whatever the other new fields
  are. (Along this line, it might be a good idea for all reserved
  zones to begin with a vlc-coded bitfield of which extended fields
  are coded, so that unused fields only consume 1 bit instead of a
  whold byte.)

I'm not completely wedded to this proposal nor opposed to different
ways of doing it, but I do believe this approach has some nice
advantages as outlined above.

Rich