[NUT-devel] info packets/frames

[Rich Felker]

On Sat, Feb 18, 2006 at 03:14:44PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Feb 18, 2006 at 02:19:00PM +0200, Oded Shimon wrote:
> > On Sat, Feb 18, 2006 at 01:57:25PM +0200, Oded Shimon wrote:
> > > On Sat, Feb 18, 2006 at 12:28:59PM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > On Sat, Feb 18, 2006 at 10:02:48AM +0200, Oded Shimon wrote:
> > > > [...]
> > > > > I still have one major issue left with info packets - chapters... We need 
> > > > > to decide a sane way to do them and say so in the spec... But that's after 
> > > > > we all agree on this patch. Does anyone have objections left...
> > > > 
> > > > i am against it, my oppinion is either store the table in the file or make it
> > > > constant, or propose to drop "extendible" from the goals first
> > > 
> > > :/
> > > 
> > > Putting the tables in the main header is very very weird. It doesn't belong 
> 
> thats my favorite reasoning why something is bad (its weird, philosophical
> wrong, not unixish, ...)
> 
> btw, you can also put them in an info packet of course if you prefer ...

If you prefer, weird means it adds to the number of data structures a
demuxer must maintain, along with seeming unnatural.

> the info packets are string name + type + value triplets, the table is
> a optimization to reduce the size, i vote for droping the table completely
> way before i agree to allowing changing the table without storing it in the
> file, the table was never intended to be changable, if you insist on changing
> it it must be stored in the file

Again we don't insist on changing it any more than we insist on adding
new nonsense fields to the main headers. But it should still be
possible anyway unless it turns out to be needed (e.g. some really
important new tag people want when NUT 2.0 comes around and it's
wasting lots of space by storing the name over and over..)

If you insist on extensions being in the global headers, I'd prefer
that we remove the table from the spec entirely and put all codes in
the global headers. At least then it's consistent. The spec can still
list the names/types of standard info items, and we can expand this
list without breaking anything..

Rich