[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Why ra_serf should not (yet) be the default WebDAV RA implementation

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 14 Nov 2008 13:12:39 -0500

Greg Stein wrote:
> On Fri, Nov 14, 2008 at 9:55 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> ...
>> You cannot relax this constraint while maintaining the promises
>> of the API.
> Fine.
> We'll rev it then. It *needs* to be rev'd anyways. It has "hex digest"
> parameters in there, rather than svn_checksum_t values. It already
> needs a rev, but that isn't an API that I wanted to touch in 1.6.
> I'd also want to clarify the pools in that API. It is simply too
> confusing when looking at them: is a pool argument intended for baton
> allocation, or for scratch usage? Or both? The docs are not clear on
> what the pool arg is intended for, nor what its lifetime is guaranteed
> to be.
> We can take a whack on the editor ordering constraints, and loosen
> any/all of them. Clarify the notion of postfix textdeltas. Enable
> props and textdeltas to be done at postfix time (tho: I think we
> *should* usually have all the props at open_file time as a result of a
> PROPFIND Depth:1 on the parent directory).
> So. API will be rev'd.

+1. Awesome. (And I agree with all of your criticisms above.)

> Is there any other blocking issue to tossing Neon?

As noted elsewhere, we need parity with Neon in its supported auth types (at
least those that Subversion takes advantage of), and with proxy support
levels. I'll let others more familiar with the situation add to this list
as needed (though I would strongly encourage said list to become tracker
issues ASAP).

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-11-14 19:12:38 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.