Dear all,
As several members of the WG get more motivated to finish the remaining
working items as quickly as possible, we are looking at the incremental
update draft (
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/)
Although I am a co-author, Wendy did all of the heavy lifting (my hats off
to Wendy!), I can give some relatively "objective" evaluation. It is
overall a quite general, elegant design.
A key factor in deciding the next step of this work item (document) is how
much to handle extensibility of incremental update encoding. In the current
design, we chose Merge Patch. With good foresight, this choice is not
"hard coded" in that it will be explicitly announced in IRD and indicated
in events. An example (Sec. 9.4) of IRD is:
"update-my-costs": {
"uri": "http://alto.example.com/updates/costs";,
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-update-media-types": {
"my-routingcost-map": application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json"
}
}
},
An example (Sec. 9.2) of flexible event encoding is:
event: application/alto-costmap+json,hops
data: { ... full hopcount Cost Map message ... }
(pause)
event: application/merge-patch+json,routing
data: {"cost-map": {"PID2" : {"PID3" : 31}}}
Hence, one can see that the design can add other incremental update
encoding options quite cleanly. For example, to better handle updates of
array elements, we are looking at JSON Patch (
https://tools.ietf.org/html/rfc6902#appendix-A.2).
There are several options to go forward:
1. Use the current design as it is, with few changes;
2. Use the current design, but add more placeholders to emphasize/suggest
how one may add a new encoding;
3. Explicitly add JSON Patch as an encoding option;
4. 3 + 2
Since this is a relatively important decision, I have decided to send out
this email to seek comments before the WG meeting. Any points, either on
the list (preferred) or private, will be greatly appreciated!
Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
