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?
