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

Re: svn commit: r27647 - in trunk/subversion: libsvn_ra_neon libsvn_ra_serf

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-09 00:59:25 CET

On Nov 8, 2007 3:57 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> "David Glasser" <glasser@davidglasser.net> writes:
> > Maybe I'm missing something (I only looked at the diff, not the
> > context), but if we're exchanging capabilities during the open call,
> > why do we need to even consider calling exchange_capabilities again
> > during svn_ra_neon__has_capability?
> >
> > (Ditto for serf.)
>
> I didn't see any reason to have svn_ra_has_capability() depend on a
> capabilities exchange having happened already, even though the current
> code does such an exchange when opening the session. That API should
> do its job even if no one else has done it already :-).
>
> (There's no performance price, obviously, since there will be no extra
> network turnaround if we know the capabilities already).
>
> > (Also, are there possible negative consequences to this extra OPTIONS
> > request at the beginning... how does it interact with authentication,
> > for example?
>
> I hadn't thought of that. Gosh, I don't know. The authn callbacks
> have already been set by then, and they get invoked (by the protocol
> layer) whenever they're needed, right?

I think my question is less "will it be ready to get the
information?", and more "will this start making password prompts show
up where they weren't before?".

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 9 00:59:39 2007

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.