httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Hackathon discussion; Pluggable Backends [was r->filename]
Date Tue, 28 Oct 2003 22:56:55 GMT
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

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.


Greg Stein,

View raw message