[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

[Michael Niedermayer]

Hi

On Fri, Mar 03, 2006 at 10:36:25AM -0500, Rich Felker wrote:
> On Fri, Mar 03, 2006 at 03:44:18PM +0100, Michael Niedermayer wrote:
> > > > absoloutely no gain. There's a pretty damn good chance that if the index is 
> > > > borked, the entire index is borked. not just a small piece of it. And the 
> > > > file still plays perfectly fine without the index... ("it will make 
> > > > <extreemly rare use case> slightly slower" ...)
> > > 
> > > its not slightly, and its not rare IMHO
> > 
> > but if you and rich prefer a single monolithic index then well lets return
> > to that, its not the most critical issue ...
> 
> I prefer a monolithic index, but more importantly I want it to be
> writable in one pass without buffering. However, in order to write an
> index you need to have buffered all the data that goes into the index
> while writing the file, and if it was possible to buffer all that then
> it should be possible to reuse that memory (if nothing else) to store
> the whole nut-format index.
> 
> Also, you could do a dummy-run first, writing the index to /dev/null
> to get its size, then once you know the size do the actual unbuffered
> write. This is similar to my recommended replacement for GNU libc's
> nonstandard asprintf: call snprintf once to get length, malloc, then
> snprintf again to store the string.
> 
> Anyway, if there are good reasons that the broken-up index is better
> than monolithic, I'm happy to consider it. However, I believe the
> possibility of one index segment being broken and the rest being ok is
> extremely rare, like Oded said, and it's also (slightly) complicated
> for a demuxer to decide what to use the partial index for in this case
> anyway.

ok, fine, lets go back to the monolithic index
ill change it back after the flags cleanup unless someone else does it
before...

[...]

-- 
Michael