If I may, I would follow this up with a suggestion that a separate I-D that provides a more complete treatment of fully-concurrent patch operations would be helpful. JSON-Patch is largely designed around atomic and sequential modification operations and is not, necessarily a great match for the kind of OT-style mechanisms Robert was referencing. I don't personally have any use cases that would require the level of concurrency Robert is suggesting but it would be an interesting pursuit nonetheless.
On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy <[email protected]>wrote: > I apologize for being absent for this thread until now. Vacation and > medical matters interfered with me keeping current. > > First, with my participant hat on: > > I've been occasionally comparing this work to conventional UNIX "patch" to > try to maintain a point of reference as these works developed. As such, > I'm swayed by the argument (which, as I recall, was part of working group > deliberations prior to WGLC) that we have the "test" operations, so people > generating patch documents should use them to ensure proper context before > applying any of the operations that alter the target. UNIX "patch" > accomplishes this by default by surrounding the lines to be changed in the > target with context lines that aren't changed, and so must exist precisely > as-is before the change can be made or the change is rejected. Consider a > target file comprising 26 lines, each containing the next character of the > upper-case English alphabet and a newline, but the M and the N lines are > swapped. A typical patch to fix this would look like so: > > --- x Mon Jan 7 20:27:36 2013 > +++ y Mon Jan 7 20:27:40 2013 > @@ -10,8 +10,8 @@ > J > K > L > -N > M > +N > O > P > Q > > The default for UNIX "diff" is to produce three lines of context above and > below the change to be made to ensure the change is being made in the right > place. One could also request no lines of context, yielding: > > --- x Mon Jan 7 20:27:36 2013 > +++ y Mon Jan 7 20:27:40 2013 > @@ -13 +12,0 @@ > -N > @@ -14,0 +14 @@ > +N > > But this doesn't bother to check any context, except of course to ensure > that the target file is at least 14 lines long. Although the top one is > clearly safer, both are actually legal patches. > > In my view, these two JSON documents present a language for referencing > and object and changing it, and also for querying for context, just like > the conventional UNIX diff/patch format does. But in neither the UNIX case > nor the proposed JSON case is the context part mandatory to use (though one > could certainly argue it's foolish to skip doing so). That seems fine to > me. > > Then, with my co-chair hat on: > > Although I hear and understand Robert's position that this is an important > thing that needs to be addressed, it is not my view after reviewing this > thread that there's rough consensus to reopen the question. Please note > that this is not an "it's too late in the process to change this" position, > but rather one that notes that the burden of supporting a change to > something that already has rough consensus is on the person proposing the > change, and I don't believe Robert has succeeded here. > > That said, I would ask the document editors to consider adding a paragraph > or an appendix indicating this issue was considered during development of > the work and the current format was deliberately selected, preferably with > some supporting text. This will ensure future readers will not interpret > the chosen design as a bug, but rather an intentional design choice. > > -MSK, APPSAWG co-chair > > On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan <[email protected]> wrote: > >> ** >> On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote: >> >> This last assertion really isn't qualified very well. >> >> >> It would have been better for me to state this is my opinion, based on >> discussions that were animated from similar objections raised in the past. >> >> Paul >> >> _______________________________________________ >> apps-discuss mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/apps-discuss > >
