>Date: Wed, 15 Oct 2014 07:04:46 -0400
>From: Xiao SHI <[email protected]>
>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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
