William A. Rowe, Jr. wrote:
Akins, Brian wrote:
On 9/25/08 2:24 PM, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
Hmmm... -0.9, it's private because the connection mechanics are private.
Core transport is part of core.
What was the rational?
Bcs lots of modules have things like this. Using mod_dialup as an example:
Of course [duh!]
But it folds back to another issue... for a long time we've chattered that
holding the apr_file_t to the designated resource, opened before-or-during
the directory_walk and forever tested from that point on using it's handle
instead of it's name would be optimal.
If we finally s&*t and get off the pot to add this in 2.4 / 3.0, and this
was determined by core which -also- opened the target file (opening it
appropriately to enable sendfile, of course), then where does that leave
us? Do we still seek this new api call?
Yes, I think we should add this API.
Pulling in CORE_PRIVATE is extremely lame, but its currently the only
way to tell if a File Path has sendfile enabled or disabled. It should
be an API.
I also wouldn't mind a API that took a char* path, and a request_rec,
because someitmes you are inserting buckets from different files, with
different paths, and the file path in the main request record isn't
always accurate.
-Paul
