Dear all, Some of us are having an extensive discussion on how to proceed regarding the ALTO incremental updates WG item. Here is a summary of what we are thinking. At a high level, we plan to propose an approach of using JSON Patch (RFC6902), but with some extensions. We want to get your comments and advice on if you see any problems, and how best to proceed.
Current state: ========== Both JSON Patch (RFC6902) and http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 are considered as candidates of the encoding update message format. Design goal and problem: ==================== Generality and efficiency. That is, we want an incremental update format that can handle not only current resources but also future resources. The recent trend in adopting YANG shows that general mechanisms, not per protocol patch, have value. Generic encoding of JSON Patch based on XPATH and a few operators is complete in this sense, but inefficient in key ALTO cases such as updating cost maps, as pointed out in http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 Key idea: ======= A JSON object can be considered as an key-value tree, with each node being an object and each edge labeled by the key, and the value of the edge pointing to another object. For example, the ALTO cost map example: { "meta" : { "dependent-vtags" : [ {"resource-id": "my-default-network-map", "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" } ], "vtag": {"resource-id": "COST-MAP-ID", "tag": "CM-TAG"}, "cost-type" : {"cost-mode" : "numerical", "cost-metric": "routingcost" } }, "cost-map" : { "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, "PID3": { "PID1": 20, "PID2": 15 } } defines a data tree with 14 leaf nodes: "meta/dependent-vtags/resource-id": "my-default-network-map", "meta/dependent-vtags/tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e", ... "cost-map/PID3/PID1": 20, "cost-map/PID3/PID2": 15 RFC6902 focuses on encoding updating one node on the tree at a time. On the other hand, one can realize that the cost-map update encoding of http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 updates a set of nodes. For example, an update example { "meta": { "vtag": {"tag": "NEW-CM-TAG"}, }, "cost-map": { "PID1": {"PID2": 10, "PID99": null} } } updates 3 nodes. If one thinks about, one will realize that this is a general, interesting design: consider the data tree of the original object; the update object is a partial tree of the original, and updates a batch containing all matched nodes in the partial tree. We call this operator the tree-replace operator. How may one do this as an extension of RFC6902: { "op" : "tree-replace", "path" : "/", // prefix of update object "value" : // just a copy of the partial object in value { "meta": { "vtag": {"tag": "NEW-CM-TAG"}, }, "cost-map": { "PID1": {"PID2": 10, "PID99": null} } } } Hence, we have a simple operator that appears to be able to fix the cost-map efficiency issue and is still general, not ALTO only. Next step: ======== - One possibility is to start to work on an extension of RFC 6902 to introduce this operator, if there is no bug. After this is done, we specify ALTO incremental updates using the new op. An issue is that this is a sequential process and may take time. - Another possibility is that we specify JSON Patch as incremental update encoding for now, losing efficiency. In parallel, we push for the new op, and when it is done, ALTO incremental updates implementation can use the new op. - A third possibility is that we define the extension operator in ALTO incremental updates document itself, and proceed quickly. Any bug in the design? Any comments or suggestions? Thanks! Richard, Wendy
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
