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 protected]>:
> 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
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
