On Thu, Sep 13, 2001 at 05:16:26PM -0500, Ben Collins-Sussman wrote:
> Ben Collins-Sussman <sussman@collab.net> writes:
> > E. Push vs. Pull models. [HARD]
> >
> > The current system pre-emptively requests info, then "pushes" it
> > at the RA layer. This is odd, given that Apache typically makes
> > a challenge and then "pulls" the info. As a result, the info is
> > effectively being cached in the session_baton until Apache pulls
> > it from there.
> >
> > So, it would be nice to switch the whole client/user-interface to
> > work with the "pull" model too. One of the main benefits of this
> > is that failed authenication can be detected *immediately*;
> > right now failed authentication is simply ignored during
> > checkout, and isn't discovered until a commit fails later on.
>
> I'm really confused regarding this last paragraph, Greg.
>
> Right now, if our authentication info *fails*, why does the checkout
> just happen anyway?
The client pushes the auth info at RA, where it is stored. But the server
never pulls it, so the info is never checked. The client lib also blindly
stores it.
> I mean, if we want to allow anonymous checkout,
> why not require that folks login as "anonymous", like CVS does?
Currently, we only require authentication for *changes*. Everything else is
readonly. Unlike CVS, we can allow reads without needing a user/password.
Since that is incredibly convenient, that is what we do.
Quick: the anonymous access for mod_dav: is it "anonymous", "anon", or
"anoncvs"? And what is the password?
It changes for every project. Not so with Subversion. You just grab it
without worry.
Now... that said. You *can* institute an anonymous user/pass for readonly
operations, too. Just a config change. But (IMO) it only harms usefulness.
> As it stands, somebody mistypes their password, and they have no idea
> until they try to commit later. It's like they get a read-only
> working copy without realizing it.
Yes, that is unfortunate. However, if we revamp to not even query for the
auth info until the *server* requests it, then we would never story anything
until commit time. When you go to commit, then the server is going to demand
auth info, and we would cache it at that point. (but we would also want to
figure out a good way to save it in the subdirs, too, so it doesn't keep
getting queried; overall defaults in your .svnrc are also handy)
> > F. Method negotiation? [HARD]
> >
> > Can the RA library (running client-side) 'discover' what methods
> > are supported by the server?
> >
> > Ideally, this list of methods returned to the client should be
> > dynamically discovered, rather than being a static list, as it is now.
>
> This is the Big Issue. Please tell me if this is possible.
As Joe mentioned, you cannot proactively discover this. The only time you
can find out what the server wants is when it asks. And that is only in
response to an attempt to do <whatever>.
Cheers,
-g
--
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