Although it's tempting to extend JSON patch, I think that doing that from the context of the ALTO WG is a bad idea, both technically and politically.
Here's another take on my approach to representing incremental update. Every ALTO full map service is, at a high level, a map from KEY to VALUE. For cost maps, the key is a src/dest pair, and the value is a number (or for multi-cost, an array). For network maps, the key is a PID-name/address-type pair, and the value is an array of addresses of that type. For PID property maps, the key is a PID-name/property-name pair, and the value is the string value. Because JSON does not allow lookup-table keys to be pairs of strings, we encode those maps as nested lookup tables. For ALTO maps, an incremental update involves replacing the value for a key, or deleting a key. That's it; a server cannot make any other changes. Given that updates are that well structured, I think a reasonable alternative to JSON patch is to use the same message format as for the original data, with the semantics that the client adds these new values to the previous version of the table, and a null value means delete that key. This should be easy for any client to handle. And it is efficient, provided that we can regard the value as an atomic unit. It may break down with something like a network map, if (say) a CIDR moves from one large PID to another. In this case, JSON Patch may be more efficient. However, because we represent a CIDR set as a JSON array, when an ALTO server asks a JSON patch library to calculate the patch from an "old" to "new" network map, the ALTO server must preserve the order of addresses in those CIDR arrays. If not, the JSON patch representation may be very inefficient. Incidentally, for network maps, an alternative incremental update message would be a map from CIDRs to PID names. Remove the CIDR from whatever PID it was in before, and put it the new PID. Null means that CIDR is no longer used. Arguably, that would have been a better model for the network map message in the first place, because it captures the semantics of a network map better than the current network map message. - Wendy Roome From: "Y. Richard Yang" <y...@cs.yale.edu> Date: Thu, July 31, 2014 at 16:50 To: Wendy Roome <w.ro...@alcatel-lucent.com> Cc: Mark Nottingham <m...@mnot.net>, Paul Bryan <pbr...@anode.ca>, IETF ALTO <alto@ietf.org> Subject: Re: [alto] JSON Patch vs. custom representation for incremental updates To make progress, here is one straw-man proposal encoding that combines JASON PATCH (RFC6902) and in-place edit. Specifically, JSON PATCH defines a set of ops. How about we define a new op, as an extension of JSON PATCH, that provides in-place override, as in Wendy's design. One possibility is to name it "override", or another name you like. It still has "path", to indicate the place of "override". Its "value" will be Wendy's encoding.
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
