Subject: [alto] Extensible incremental update encoding discussion thread

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 30 Mar 2017 21:01:45 -0400

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

---

From: Shenshen Chen <[email-masked]>
Date: Fri, 31 Mar 2017 19:16:19 +0800

Dear Richard and all,

I'd like to give some comments.

The option 2 looks pretty nice for me. Consider {Entity ->
Property-changes}, there could be a specific and fine-grained encoding for
each type of property (e.g., single-value and array). Also, I wanna
"removing an Entity" event, may be encoded as data: {"network-map": {"PID2"
: "null"}}.

I don't like JSON Patch. A JSON Patch { "op": "add", "path": "/foo/1",
"value": "qux" } could be converted into:
"add":{ // To follow the format in the previous design, it should be noun.
Using "addition" may be better
    "foo": {
        "1": "qux" // "foo/1" means the first element in array "foo"
    }
}
The fundamental difference is it allows an arbitrary number of hierarchies,
which brings complexity and even impact on compatibility.

Best Regards,
Shenshen

2017-03-31 9:01 GMT+08:00 Y. Richard Yang <[email-masked]>:

> update draft (https://datatracker.ietf.org/doc/draft-ietf-alto-incr-
> update-sse/)
>
> array elements, we are looking at JSON Patch (https://tools.ietf.org/html/
> rfc6902#appendix-A.2).
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>