[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: Greg Stein <gstein_at_gmail.com>
Date: Fri, 14 Nov 2008 10:05:35 -0800

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.


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. Is there any other blocking issue to tossing Neon?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-14 19:05:49 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.