[NUT-devel] info packets/frames

[Rich Felker]

On Thu, Feb 16, 2006 at 04:28:44PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Feb 16, 2006 at 08:01:38AM +0200, Oded Shimon wrote:
> [...]
> > > > > > > just store the f* table in the main header :)
> > > > > > 
> > > > > > Bleh. :) It's a nice solution, but it's somewhat bad in that it adds info 
> > > > > > stuff in essential, small, main header (slightly defeating the purpose). 
> > > > > > Also it makes it harder for us to enforce our premade headers... (utf-8, 
> > > > > > etc.)
> > > > > 
> > > > > we cant enforce that anyway, just becaue it has utf-8 as type doensnt mean
> > > > > it is utf8, if someone decides to ignore a rule in the spec which says only
> > > > > utf-8 allowed, then he will care little about the type being enforced to utf-8
> > > > > actually later is worse as its undetectable, so IMHO better give "them" an
> > > > > option to specify that they violate the rules instead of making it impossible
> > > > > to specify the type while obviously not preventing them from storing things
> > > > > in their native encoding ...
> > > > 
> > > > That's somewhat a good point, but still not excuse enough IMO to put the 
> > > > info types in the main header, it literally defeats the purpose - info 
> > > > stuff goes in info packets, not in main headers...
> > > 
> > > then my vote is to simply not allow extending the table, its not needed
> > > anyway to add new fields to info packets
> > > 
> > > you either have a fixed table or you store the table in the file
> > 
> > Is the problem old programs not understanding new fields? It's not a big 
> > issue IMO...
> 
> if the id->string table is in the mainheader, every demuxer new and old
> will support it, if its not in the main header and we dont force muxers to
> use litteral strings as id then the values are not useable by old demuxers and
> there simply is no need to be able to parse them, just skip the rest of the
> info packet and require muxers to order fields by "age"

I'm against additional requirements like this when we already have a
good solution whereby all keys are parsable even if their contents are
unknown.

> also note that such unknown metadata would be not transcodeable to other
> containers, and even nut->nut might be hard over some (de)muxer APIs
> 
> also keep in mind not everone will update their sw every month to support the
> new info types

As I said this is not an "every month" thing. It's just in case we
eventually find a need for new types.

Aside from a few important ones, info is always an "optional" thing.
It's metadata, not part of the content itself, and it's no big tragedy
if an old demuxer can't demux part of it. (In fact there's probably no
use to having an old demuxer support it.)

Rich