On Wed, Oct 1, 2008 at 9:37 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Oct 1, 2008 at 10:31 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Ben Collins-Sussman wrote:
>>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>>> Mark Phippard wrote:
>>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>>> do this too though. As I said, I think this is a great idea and even
>>>>> overdue.
>>>> wc-props are optional -- we could ditch them today.
>>>
>>> ...at the cost of making ra_neon even slower. :-)
>>
>> Not if we simply dispense with this nonsense of treating the !svn URLs as
>> opaque and mysterious.
>>
>> And another easy-win speedup would be for our DAV clients to stop using 12
>> PROPFINDS to do simple URL negotation -- we could have long ago written a
>> custom REPORT to answer those kinds of questions in a single turnaround.
>
> Do we even need to do this URL negotiation? Couldn't we just switch
> to making assumptions about the URL's and dispense with all of this?
>
> If we have to continue to maintain mod_dav_svn anyway for older client
> support, would it make sense to just add new features into current
> library? Such as custom REPORT requests etc? Does the fact that the
> current library is related to DAV block us from doing any of the
> things you want to do?
Is it theoretically possible to move in this direction? Sure.
mod_dav_svn is currently a strange mix of baroque DeltaV formalities
and custom svn REPORT requests. We could just 'evolve' mod_dav_svn to
drop more and more of the DeltaV formalities, until it basically
becomes nothing but a big heap of custom REPORT exchanges. But I
argue that this will make mod_dav_svn even harder to read and
maintain. While ra_neon / ra_serf might be able to simplify their
chattiness, mod_dav_svn just keeps growing in complexity, getting more
and more special cases heaped on, and still all going through
mod_dav's vision of the universe. It contradicts the goal of making
an HTTP layer which is easily readable and maintainable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 16:53:33 CEST