On Wed, Mar 27, 2013 at 12:22 PM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Discussing the behaviour of the backward-compatibility APIs:
>
>
> Bert wrote:
>> I don't think the strict ordening will be a problem for old clients at the
>> client level. We don't promis ordering in the ra layers anyway and we have
>> changed the ordering many times before. As long as we call the callbacks I
>> think clients would be fine. And it will solve the existing problem of
>> broken operations when the network layer times out on a long callback
>> invocation.
>
> I am not concerned specifically about the *order* of the notifications, but rather the *kind* of notifications. The notification callbacks are now going to have their status field set to (the API representation of) 'conflicted', like this (showing the output from 'svn' just as a way to represent what happens in the API):
>
> $ svn update --accept=mf
> Updating...
> C wc/A2/B
> C wc/A2/mu
> Resolved conflicted state of 'wc/A2/B'
> Resolved conflicted state of 'wc/A2/mu'
>
> An old client expecting notification status 'updated' or 'merged', like this:
>
> $ svn update --accept=mf
> Updating...
> U wc/A2/B
> U wc/A2/mu
>
>
> ... may be confused if it actually looks at the notification status rather than merely displaying it to the user.
Just setting aside API users for a minute. Is the first example above
what the command line will show? If we are happy with that output for
command line users, then as an API user I am sure I can make it work
for me.
As a command line user, I am not sure what I think. I imagine some
users will be confused by this and ask questions about the behavior.
But it also makes sense to me, so I do not personally think it is
something I would be hung up on.
If we are happy with this behavior for the command line output, then I
am OK with it at the API layer. Thanks for the example though. I do
now have a better understanding of the question.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-03-27 17:31:57 CET