httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Collins-Sussman <suss...@collab.net>
Subject Re: bumping mod_dav
Date Fri, 27 May 2005 01:27:50 GMT

On May 26, 2005, at 12:38 PM, Sander Striker wrote:
>
>> If you've got patches handy, and can start throwing them to the  
>> list, then
>> it could be possible to squeak them in.
>>
>
> Indeed.  Ben, fire away!

OK... I'm working on the patches now.  They involve creating a
dav_provider2 structure which will be registered as version "2" with
ap_register_provider().  It means tweaking mod_dav machinery to accept
both old and new providers.

Before I make the changes, though, I want to make sure folks are okay
with the APIs I plan to change:

1.  We want mod_dav_svn to handle POST requests.

     mod_dav currently passes REPORT requests to
     provider->vsn_hooks->deliver_report().  But for POST, it merely
     validates the resource and then DECLINES.  So while it's still
     possible for a provider like mod_dav_svn to register itself to
     handle POST requests (via normal apache hooks), it's really
     inconvenient.  Does it seem reasonable to add a new do_post()
     method to the vsn_hooks vtable?

2.  Providers need to access the MERGE request body.

     At the moment, mod_dav_svn is accessing the MERGE request body
     through a hack: it registers a custom input filter which captures
     the request body in an xml doc and stashes it away for later.
     This hack can be removed if we change vsn_hooks->merge() to accept
     an xml doc.  Everyone okay with that?

3.  It's awkward to create a lock.

     mod_dav first calls lock_hooks->create_lock(), which merely
     generates a lock-token UUID.  Then it turns around and calls
     lock_hooks->append_locks() to attach the lock to the resource.
     The vtable forces the provider to separate token-generation from
     the act of locking, which is a bit odd.  I'd like to add a new
     vtable function which does everything in one step: that is, allows
     the provider to generate the token and attach the lock all at
     once.  Sound good?


Mime
View raw message