On May 26, 2005, at 10:11 PM, Greg Stein wrote:
1. We want mod_dav_svn to handle POST requests.
[...] 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_.
Yeah, you're right. REPORT is there because it's deltaV. POST isn't
webdav or deltaV at all, it's just generic HTTP. It's probably more
'correct' to just have mod_dav_svn register it's own POST handler.
3. It's awkward to create a lock.
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)
I think I disagree here, in general. The current API is convenient
for the way mod_dav_fs happens to implement recursive locking
operations: loop over a filesystem, attach the same lock to
everything. But for a provider that has a locking implementation
*built into* the filesystem, it's much nicer to assume that the
filesystem itself will handle the looping and attaching internally.
At this point, though, we've already warped svn_fs.h to match
mod_dav, so it would be too late to get any real benefits from an
alternate locking API anyway.
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.
At this point, it seems like diminishing returns. It's going to be
quite a bit of work to add a whole versioning/compatibility layer to
mod_dav... and for what? Just so mod_dav_svn doesn't have to snarf a
MERGE request body via input-filter? It seems silly to bump the
whole provider API for one tiny change to vsn_hooks->merge().
It's probably just best to table this proposal. I'll add this MERGE
change to a new queue of API changes, and someday when there's at
least 3 or 4 changes queued up, I'll propose bumping mod_dav's API
again. It just doesn't seem worth it right now.
Carry on, nothing to see here...
