On Wed, Jun 29, 2011 at 11:16 AM, Paul Burba <ptbu...@gmail.com> wrote: > On Wed, Jun 29, 2011 at 4:48 AM, Julian Foad <julian.f...@wandisco.com> wrote: >> On Tue, 2011-06-28, C. Michael Pilato wrote: >>> On 06/28/2011 01:37 PM, Paul Burba wrote: >>> > Hi Julian, >>> > >>> > I hadn't realized using in-out parameters was considered such bad >>> > form. >>> >>> At a minimum, they force an API divergence in our bindings layers. +1 to >>> separate and explicit in and out parameters. >> >> Hi Paul. As you noticed, we do use in-outs sometimes, at least >> privately, so it's not always considered such bad form, but in this case >> it looks like using separate params would be better for at least a >> couple of reasons. I wasn't even aware of the bindings issue. >> >>> > If we need to change this, then your second alternative, splitting >>> > the parameter into two, seems the more straightforward option. >>> > I'm happy to make the change if that is what we want. >> >> Thanks. >> >> I will just ask once more: as a matter of principle, are we comfortable >> it's OK to provide only an indication that "the server did in fact do >> this for you this time", but not to have a way of finding out in general >> whether the server is capable of doing this? > > On further reflection, I think using a server capabilities check is > the better approach: > > First, it is consistent with our current approach in similar circumstances. > > Second, it eliminates pointless round-trips when a 1.7+ client asks a > 1.5-1.6 server to validate inherited mergeinfo. The server obviously > can't do it, but returns the inherited mergeinfo, along with the > output parameter which effectively says, "Here's your answer, it's not > what you wanted so you probably can't use it, so, uh, why are you > asking me this?". With a capabilities check, the capability is cached > by the RA layer and we can avoid asking the question in the first > place. > > I'll add the new capability if there are no objections.
Done http://svn.apache.org/viewvc?view=revision&revision=1141981 > Paul > >> - Julian >> >> >> >
