On Oct 7, 2009, at 5:37 PM, Graham Leggett wrote:
Brian J. France wrote:
Sorry for the delay in response to this, life got in the way.
I have updated the patch here:
http://www.brianfrance.com/software/apache/dav/dav-provider-3.diff
This patch doesn't break binary compatibility (adds the functions
to the
end of the struct) and adds both get_request_rec and get_pathname.
While in most cases you can pull pathname from the request_rec, how
would you get the pathname from a mod_dav_fs_db type module? Should
mod_dav_fs_db update r->filename or should we keep the get_pathname
function in the provider struct?
Either way works for me, just happen to have a discussion at work
about
writing a custom mod_dav_fs module and thought of this patch case.
Just a quick check - am I right in understanding that the get_pathname
function below is an oversight?
Index: modules/dav/main/mod_dav.h
===================================================================
--- modules/dav/main/mod_dav.h (revision 822497)
+++ modules/dav/main/mod_dav.h (working copy)
@@ -1940,6 +1940,12 @@
** then this field may be used. In most cases, it will just be
NULL.
*/
void *ctx;
+
+ /* return request record */
+ request_rec * (*get_request_rec)(const dav_resource *resource);
+
+ /* return path */
+ const char * (*get_pathname)(const dav_resource *resource);
};
Depends.
Should a mod_dav_fs type module (like mod_dav_fs_database) update r-
>filename so other modules like mod_dav_acl could use the filename
from the request_rec.
Or should mod_dav_acl use a hook function to get the pathname because
r->filename would not be set correctly since that is a path on disk in
the case of mod_dav_fs_database?
My patch (version 3) left the get_pathname hook with the assumption
that r->filename should not be used and instead a hook should be used.
Brian
