Subject: Re: [alto] ALTO incremental updates and JSON Patch extension

From: Wendy Roome <[email-masked]>
Date: Thu, 16 Oct 2014 10:19:18 -0400

>Date: Wed, 15 Oct 2014 07:04:46 -0400
>From: Xiao SHI <[email-masked]>
>Subject: Re: [alto] ALTO incremental updates and JSON Patch extension
>
>Hi folks,
>     ......
>
>Building on top of what Richard said, the set-like array may also be an
>issue if it is in the middle of the targeted path. For example, if I have
>the following object (Sec. 11.4.1.6 of RFC7285 with one added element in
>the dependent-vtags array):
>====
>{
>  "meta" : {
>    "dependent-vtags" : [
>      {
>        "resource-id": "my-default-network-map",
>        "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
>      },
>      {
>        "resource-id": "my-alternative-network-map",
>        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
>      }
>    ]
>  }
>}
>====
>Let's say we want to modify the tag of the default-network-map (which
>seems
>reasonable). Correct me if I'm wrong, but without knowing the specific
>index of the array, this task would not be possible with JSON patch or
>merge patch (since merge patch does not iterate through arrays).
>
>Best,
>Xiao

In this case, merge-patch would just replace the dependent-vtags array in
its entirety. That's less space-efficient, of course. But that array will
never be very large, so that doesn't hurt much.

But it will be significant if we use merge-patch for incremental Network
Map updates. If PIDs have 50+ prefixes (large, but certainly not
impossible), if a prefix moves from one PID to another, merge-patch would
have the give the complete list of prefixes for both PIDs. In the extreme,
if one prefix changes in every PID, the merge-update message would be no
smaller than the full network map message, even though only a small
fraction of the prefixes changed.

	- Wendy Roome