[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-09 00:57:57 CET

"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?

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:58:09 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.