Vlad Georgescu wrote:
> On 6/5/06, Daniel Berlin <dberlin@dberlin.org> wrote:
>> Vlad Georgescu wrote:
>> > Properly implementing SASL support in Subversion will require some
>> refactoring:
>> >
>> > * On the client side:
>> > Authentication is performed by the following functions in
>> > subversion/libsvn_ra_svn/client.c : find_mech, auth_response,
>> > read_success, do_auth. (There's also handle_auth_request, but it only
>> > checks to see if the mechansm list is non-empty and then calls
>> > do_auth).
>> >
>> > Basically I want to extract these functions from client.c and put them
>> > in another file (say, "old_auth.c"). The entry point for
>> > authentication would be do_auth. I would then create a new file
>> > "sasl_auth.c" that also exports do_auth but does authentication
>> > through Cyrus SASL.
>> >
>> > The idea is to conditionally compile and link only one of those files
>> > depending on whether or not SASL is present on the system.
>>
>> Uh, normally we just create an interface and have both implement it, so
>> that conditional compilation only changes whether we have a given
>> interface provider available.
>>
>> Then you can just choose from the available ones at runtime.
>
> I agree with this on the server-side, but on the client-side I can't
> think of a reason why you would ever use the old code over the SASL
> implementation, if SASL is available.
Do the SASL mechanisms completely (functionally and semantically)
replace the auth methods we have in place now? E.g., what happens if the
client is built (as you suggest) to only use SASL, but talks to an older
server that doesn't use SASL?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 5 10:56:37 2006