On Wed, Jun 29, 2011 at 11:16 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Wed, Jun 29, 2011 at 4:48 AM, Julian Foad <julian.foad_at_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
>>
>>
>>
>
Received on 2011-07-01 18:32:19 CEST