On Wed, Mar 27, 2013 at 12:22 PM, Julian Foad <julianf...@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/
