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

Re: authentication progress...

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-18 01:55:38 CEST

On Mon, Sep 17, 2001 at 05:33:09PM -0500, Ben Collins-Sussman wrote:
> Dale Thatcher <subversion@dalethatcher.com> writes:
> > In the above code couldn't the get_username and get_password be
> > collapsed into a single get_auth(username, password, auth_baton,
> > pool)? The same could go for the store method. Is there a reason
> > they need to be separate?
> No reason they *need* to be separate.
> The reason they're separate: it just happens that right *now*, both
> authentication methods are sharing a common 'get_password'
> implementation in libsvn_client.

I'm with Dale on this one, and it was part of my rationale earlier for
avoiding the "list of items to fetch via callback". Consider the case where
the username and password are fetching at the same time, via a GUI dialog.
By breaking the get_ into two pieces, then you severely complicate the
callback's job. It will have to fetch both pieces, then save one aside
somewhere, and then have get_password pick that back up. Ugh.

Also, consider the "save" case. By breaking it into two pieces, you enforce
the use of two files, or the callbacks would need to open the file, add or
replace the info, then save the file back. In both cases, it is a good
amount of I/O. If the save was a single callback, then the callback could
write out a single file with both pieces of information.

[ I know you're just about done and ready to check this in; that's fine, but
  a second pass would combine that vtable into single points. ]

re: your common "get_password". Just have a single callback and then call
your get_password twice :-)


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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.