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

[Michael Niedermayer]

Hi

On Fri, Mar 03, 2006 at 01:11:50PM +0200, Oded Shimon wrote:
> On Fri, Mar 03, 2006 at 12:30:22AM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 02, 2006 at 05:16:23PM -0500, Rich Felker wrote:
> > > My objection to upper bound on max_distance had nothing to do with
> > > size. I'm sorry I wasn't clear.
> > 
> > and what is the terrible thing which will/could happen if there where
> > an upper limit? i mean from the user or developer perspecitve (complexity, 
> > speed, overhead, ...)
> 
> I could just as well ask - what does the user/developer GAIN from there 
> being an upper bound? 

yes you can and should ask, it makes it much harder to generate broken files


> yes, if there is no upper bound you can make a broken 
> file, but you can ALWAYS make a broken/inefficient file if you are being 
> deliberately ignorant...

master we have 2 issues, lets call them A and B
without fixing A the user can make a broken file
without fixing B the user can make a broken file too
now fixing A is a bad idea as the user still can ALWAYS make a broken/
inefficient file if he is deliberately ignorant (by using B)
now fixing B is a bad idea as the user still can ALWAYS make a broken/
inefficient file if he is deliberately ignorant (by using A)

so what do we do, yes we fix neither
i like your arguments, they are amusing


> 
> > not the idealist/philosopher perspective (its wrong,
> > bad design, this is like <infamous container> does it, it will make 
> > <extreemly rare use case> slightly slower, ...)
> 
> To this same sentiment, I ask, what is gained from your new index system? 
> You never replied to my rant.. Yes you did make it optional which makes it 

error robustness and easier muxing for muxers which are not based on libnut


> somewhat nicer, I am still annoyed by the index_ptr and the additional 
> demuxer complexity for this index system (reallocing the syncpoint cache 
> for each index chunk, reading several chunks...), mostly because I see 

you need that for dynamic index building too if theres no index at all, and
iam not against adding a syncpoint_count field which would provide you with
the number of syncpoints in the whole index


> 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

[...]
-- 
Michael