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 <superuser@xxxxxxxxx> wrote:
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.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.Then, with my co-chair hat on: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.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.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: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
--- x Mon Jan 7 20:27:36 2013
+++ y Mon Jan 7 20:27:40 2013
@@ -13 +12,0 @@
-N
@@ -14,0 +14 @@
+N
-MSK, APPSAWG co-chairOn Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan <pbryan@xxxxxxxx> wrote:
On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote: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.
This last assertion really isn't qualified very well.
Paul_______________________________________________
apps-discuss mailing list
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss