Ben Collins-Sussman wrote:
>Justin Erenkrantz <justin@erenkrantz.com> writes:
>
>
>
>>Getting mod_dav to be streamy may be just as hard as getting the pool
>>usage right. =) But, perhaps not. Let me know if you need any help.
>>
>>
>
>Ugh, this looks really hard.
>
>dav_method_propfind has many call layers below it, and they *all*
>assume that the provider is writing into a text-buffer. When control
>returns to the top level, it sends out the whole buffer.
>
>What we really want is for dav_method_propfind to look like
>dav_method_report: create an output filter, pass it down to the
>provider. The provider creates a brigade and spews data into it.
>Voila, instant streaming.
>
>But this looks like a total rewrite of dav_method_propfind to me. :-(
>
>
>
I actually went and implemented bucket brigade streaming for this in the
past while trying to reduce my httpd memory consumption, but I have no
clue where my patches went to...
It was pretty quick and easy to do, except for two issues that I ran
into which made me drop the whole thing. They shouldn't be too
difficult to get around if you know the dav specs better than I do.
1) Inside dav_method_propfind(), two different headers could possibly be
sent depending on whether the ctx.propstat_404 bit gets set. Here's the
comment by the piece of code in question in mod_dav.c line 1987:
/* if a 404 was generated for an HREF, then we need to spit out the
* doc's namespaces for use by the 404. Note that <response> elements
* will override these ns0, ns1, etc, but NOT within the <response>
* scope for the badprops. */
2) dav_send_multistatus() needs to know which "xmlns:" attributes need
to be set in the <D:multistatus> tag. This would require making
resource->hooks->walk() a two step process. The first step would be
required just to ask the provider for the namespaces that need to be
added to the multistatus tag. Then you could send the header and run
resource->hooks->walk() to stream the data.
BTW, Its been awhile since I did this, so I don't remember if this 100%
correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 30 04:59:41 2003