Other outstanding issues that IMHO can/should be fixed in 1.0.
Configure issues:
1) dealing with APR_HAS_LARGE_FILES on linux http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2 Currently it's just disabled, even when available. the whole thread is here: http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
IMHO, this isn't a 1.0 showstopper. Someone who has a Linux box can step up and add the right configure logic. No API change is required here. We don't need to hold up 1.0 because no Linux developers care to fix it. (I don't have access to Linux boxes with working sendfile64, so I'm of zero help here.)
1) apr_strfsize is limited to the availability of LARGEFILES support, whereas it's advertised as a general purpose function and has nothing to do with the filesize. The thread that wasn't finished is here: http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
I'm not understanding why this is related to LARGEFILES at all? Do you mean that you'd want this to work with 64-bit integers regardless of apr_off_t's size? Don't see that as 'must-fix' before 1.0.
2) s/ap_ht_time/apr_date_format_http/g http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2 Bill says it's a good API change (move into apr): http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
According to the version rules, functions can be added at any time. Again, not a 1.0 showstopper.
3) there is no apr_file_tell http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2
Cliff and I just talked about how you'd solve this in #apr. He's writing a reply now. -- justin
