On Wed, May 16, 2012 at 5:15 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 05/16/2012 06:46 AM, Greg Stein wrote:
>> Short query: is this possible?
>
> I know of no convincing reason why we cannot someday delete libsvn_ra_neon.
> I am very much in favor of getting back to a single DAV provider. I
> believe that ra_serf offers us the best path forward along those lines, not
> because it is demonstrably "better", but because it has our developer
> inertia and we've a tighter cross-community connection with the Serf project
> than we do the Neon project.
>
>> We have some issues filed against ra_serf. Which of them should be
>> considered as blockers?
>
> Having not reviewed the issues myself, I can only submit the following
> litmus test of ra_serf readiness: can it do everything that our current
> user base expects ra_neon to do? I don't see any reason to make it more
> complicated than that. I strongly wish to *not* have to tell any user,
> "Sorry, you can't upgrade to Subversion 1.8 because we decided to drop
> support for that Windows Kerberos NTLM Snozwaggle 8.2 support you were using
> in ra_neon that ra_serf doesn't offer." Until that time, ra_neon must remain.
>
Serf has full Kerberos/NTLM implementation on Windows and *nix. So
it's not issue. Probably implementation has some bugs, but I've used
it for along time without serious issues.
I didn't tested but most likely serf doesn't support OpenSSL
authentication using client certificates stored smart cards. But this
is different issue than Kerberos/NTLM.
--
Ivan Zhakov
Received on 2012-05-16 15:47:37 CEST