On Tue, Oct 28, 2003 at 03:57:08PM -0600, William A. Rowe, Jr. wrote: > At 03:25 PM 10/28/2003, Geoffrey Young wrote: > > >>I'd like to take up and hack through some solution at the hackathon - this > >>is the sort of underlying schema that we could fix in 2.2 - but we can come > >>up with agreement on 'one true way' more rapidly with face time.
I'd like to talk about this stuff, too. > >ok, I'll hold off on spending any time on it now, then. > > > >guess I need to sign up for the hackathon, too :) > > Develop your ideas to present, on the list or there. I'm suggesting it's a pretty > rich topic. BTW - do look at mod_dav_fs to get a handle on what I'm looking > at. Also consider we need; Well, see modules/dav/main/mod_dav.h and the dav_hooks_repository vtable. > *) an API for listing members (e.g. dir_read) mod_dav uses a "directory walk" metaphor. It walks over the resources and performs a callback. Having a "list directory" is a bit more useful in many cases. I chose the walk metaphor because mod_dav might need to do a full tree recursion, which is a bit harder to organize thru a list dir scheme. Note that there would be a concept of a "resource" in a pluggable backend (see dav_resource). Resources can be a bit more than just a pathname, which means it could be expensive to create a whole mess of them. listdir is also unworkable if you have a virtual "directory" of resources. For example, in Subversion, there is a "directory" which has a child resource for *every* revision in the repository. When the repository contains tens of thousands of revisions, then the listdir style is unworkable. You want the walker code to iterate over each child, and managing a subpool as it does that walk. > *) an API for opening a member and for fetching data See dav_hooks_repository.get_resource() > *) an API for getting a bucket representation (e.g. sendfile/mmap/heap) Rather than retrieving a bucket, I chose to have the backend "inject" the resource into the output filter stack. See the deliver() vtable function. For a resource that is very complex, it is easier to have the resource perform the injection rather than requiring it to provide a bucket. This allows the resource to do things like ap_fputs() rather than always instantiating buckets. (but, of course, it can construct a brigage and insert it into the filter stack) Note that a concept of metadata is always required for the resources. When you look at something like mod_autoindex, you want to find out things like size, last modification date, etc. For metadata, I don't know that you really want to look at mod_dav, though. Those interfaces are not very clean / easy to figure out. Given that some metadata is computed on the fly, I would suggest an accessor function rather than representing metadata as a hash table. To keep the system general, I would suggest a 'const char *' for the name, and a binary ptr/len pair for the value. Cheers, -g -- Greg Stein, http://www.lyra.org/
