Well, now that the uri stuff is now in apr-util, the biggest one left (IMHO) is util_date.c. My plan is to come up with a similar series of patches for apr_date.h. Should a new directory be used (date)? I also have some additional formats that don't quite fit the HTTP RFC, but that I saw in the creation of mod_mbox (various degrees of RFC 822 compliance) - so I might add another function (apr_parseRFCdate?) which attempts to parse a wider range than what the HTTP RFC specifies - this might be useful for some other applications, I think.
Also, the other potential candidate I identified earlier was util_md5.c. But, it seems that util_md5.c relies on apr/passwd/apr_md5.c. I tried to track down usage of apr_md5 within apr itself, and the only usage I could find was in apr/misc/unix/getuuid.c which will only uses apr_md5 when APR_HAS_RANDOM is not defined (typically /dev/random doesn't exist - i.e. Solaris doesn't have it, or truerand isn't available). This seems odd. It just md5s the current date/hostname/pid to produce a "random" string of the requested length. I *guess* it's random enough. Now, I'm not sure what the dividing line is between apr and apr-util, but my gut tells me that md5 hashing doesn't belong in apr itself. I think a better (IMHO) solution (if I interpret the use of md5 in getuuid.c correctly) is to introduce some PRNG into apr and move md5 into apr-util. This also has the side effect of guaranteeing that there is always some PRNG available. As I see it, this PRNG would be used as a fallback when /dev/random and friends aren't available. I bet there are some free PRNGs (BSD-license of course) flying around that could be used, or we could try to come up with one of our own. I'd rather not reinvent the wheel (PRNGs aren't trivial), but hey, I'm game. Maybe a better solution to the PRNG is try to leverage rand() somehow, and coersce it to fit the apr_generate_random_bytes prototype. Make the rand() % CHAR_MAX for each byte. That is simplisitic and wouldn't be that efficient. We'd also have to determine whether any PRNG is good enough for inclusion with APR for when it is used as a fallback. I don't think including a sub-par PRNG is a good idea (any idea what the definition for a sub-par PRNG is? <G>). You'd also have to deal with seeding the rand() function (in apr_initialize?). Thoughts? -- justin
