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.
Paul
> - Julian
>
>
>
Received on 2011-06-29 17:17:12 CEST