> "David Reid" <[EMAIL PROTECTED]> writes: > > > Ben's point is more (I think) that if we say we're providing randomness then > > we should provide that. > > But a caller isn't allowed to *explicitly* ask for poor-quality, > non-blocking randomness? Why not? If the word "randomness" bothers > people, then let's create a new function that never uses the word: > apr_generate_bits_nonblocking() or something. > > Nobody is arguing that we shouldn't have a function that produces > high-quality randomness. Most of the time, that's what people want. > But we *also* need the ability to produce very poor randomness which > doesn't ever block for entropy.
Why? Please provide some cases that aren't SVN specific... > > Bear in mind that APR could be used for a lot of > > things, and having a potentially very weak random function isn't going to > > cut it in a lot of places. > > I'm not advocating a weak random function. I'm advocating either one > function with a 'strong/weak' boolean flag, or two separate functions, > one for strong/blocking, one for weak/non-blocking. > > Subversion, right now, needs to generate some poor-quality > pseudorandom bits, and it *cannot* block. Yes, it's a bit unusual, > but not an outrageous request. Are you sure? Once more it's altering apr to accomodate SVN. APR should do the right thing in all situations. APR is a general purpose library, not a place to add svn specific functionality. > > FWIW I've seen the sort of api that Ben alludes to elsewhere and don't see a > > huge problem in using it. That said ben is the math's wunderkind for this > > stuff so perhaps he can provide an overview of what his proposed api would > > look like to allay fears. > > He did give a very detailed overview of his proposed API, if you go > back read his original response. The problem is that I haven't the > first idea of how to start implementing it. And his API seems to > focus on passing parameters that tweak the quality of the randomness, > but for Subversion, what really matters in the non-blocking aspect. Well, if you want randomness you want randomness. If you want psuedo-random bytes that don't block that's what you want. I don't see how changing our randomness to simply not block is the right thing. Also passing in flags doesn't strike me as being a clever thing to do. "...using APR I called the random function with a non-blocking flag and it gave me shit..." That sort of comment would become a reality and simply saying "it's in the documentation" doesn't really solve it for me. If you really want something like this then you need to add a new api that differentiates between what you want and the randomness that we strove so hard to provide. david
