On Thu, Nov 13, 2008 at 5:13 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Nov 13, 2008 at 7:52 PM, Hyrum K. Wright
>...
>> Frankly, serf won't be on par with Neon until it's the default dav ra method,
>> and it gets more everyday usage.
>
> There has got to be a better way than that. With a product as mature
> as Subversion we cannot just switch users to Serf if we are not highly
> confident it is going to behave as well as Neon.
Yes, we are highly confident.
>> Oh, and maintaining two dav ra layers is the sure way to madness. If/once
>> ra_serf is the default, let's just nuke ra_neon and be done with it.
>
> This makes sense, but I'd like to see someone do a feature comparison
> of what each can do before we just nuke neon. I know that ra_serf has
Go ahead :-)
> added support for a lot of the same authentication mechanisms that
> Neon supports, but I think Neon still supports some that Serf does
> not. For example, I know there are people that have deployed Neon in
> a Smart Card environment with PKCS#11 certificates. Can we just take
> that away from those users? Has Serf added this?
If core Neon can do that, then yes, we'll add it to serf. If those
users have local mods, then no, we won't add it.
But switching to serf will not be a regression in functionality.
> Another issue that has been raised in the past is that ra_serf does
> not honor the depth-first editor API contract. That would need to be
> fixed as part of becoming "official".
Fixed or loosened. Personally, I think it should be loosened in order
for us to get systemic performance increases. The depth-first
requirements are too binding.
Cheers,
-g
---------------------------------------------------------------------
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 07:51:04 CET