On Thu, May 26, 2005 at 08:27:50PM -0500, Ben Collins-Sussman wrote:
>...
> 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.
Yup. And for providers to supply both (so they can interop with older
servers).
> 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?
Knee jerk is "handle it yourself". But the more considered response notes
that mapping from a URL to a DAV resource would be a pain without mod_dav
to assist.
However, the types of responses that could be performed from a POST are
all over the map. I'm a bit wary of a vtable hook that merely gateways an
arbitrary set of functionality. Further, it would not belong to the
vsn_hooks vtable -- that is for DeltaV stuff which POST is most decidedly
_not_.
My recommendation is to have dav_method_post() hang the dav_resource()
onto the Apache request resource (r->pool's user table). mod_dav_svn can
use standard Apache handling to process the POST, and can pick up the
dav_resource in its handler. Note that you will want to order the handlers
to ensure that mod_dav_svn runs *after* mod_dav.
> 2. Providers need to access the MERGE request body.
>...
> This hack can be removed if we change vsn_hooks->merge() to accept
> an xml doc. Everyone okay with that?
Definitely.
> 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.
Not odd at all -- just for Subversion since it does not have collection
locks. For a collection lock, mod_dav will create one lock structure, and
then recursively apply that lock to all resources in the collection.
(apply meaning "append" since a resource can have multiple, non-exclusive
locks on it)
Also note that the control flow is:
1. PROVIDER: create a basic lock structure
2. MOD_DAV: fill in lock structure with data from the LOCK req body
3. MOD_DAV: validate applicability of lock based on req body params
(specifically, exclusive vs shared locks)
4. PROVIDER: apply the lock to relevant resources
You could probably parse the body up front, and pass that into the lock
creation. But the validation step must still happen.
> 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?
Does this strategy also apply to mod_dav_fs and mod_dav_lock? IOW, they
should use the same mechanism. I'm assuming they do not require the vtable
entries to be separate?
It seems like what you're planning on doing is have dav_method_lock
examine the depth of the lock. If it is depth 0 (a member resource, or a
locknull member/collection resource), then it could use your "all in one"
vtable entry. If it is depth infinity (for a collection; depth infinity on
a member must be ignored), then it uses the old entry points.
You're going to be doing a good bit of monkeying around with the control
flow to get this one-shot vtable entry to work. Doable, yes, but probably
not as straight-forward as you intended...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
