I respectfully disagree that using JSON Patch for cost & network map
incremental updates would make it any easier to provide incremental update
for future services.
You¹d have a point if JSON Patch solved the whole incremental update
problem without any additional protocol specification. E.g., if we could
just say, ³For incremental update, use JSON Patch [RFC 6902]², and Shazam!
we have incremental update.
Unfortunately it¹s not that easy. The format used to represent the deltas
JSON Patch vs service-specific update commands is only a small part of
the incremental update mechanism. For an incremental update service to a
map, we have to specify how the client locates the service (e.g., its
media type), how the client tells the server what version the client has
now, etc, etc.
Of course, if it turns out that JSON Patch is a good way to represent the
deltas for the CDN services you mentioned, then the associated incremental
update service an use JSON Patch. But we still need to define that
service. And that would require a new RFC, or at least a section in a new
RFC.
BTW, one of the problems I see with JSON Patch is that JSON does not
define a ³set² type, so everyone uses arrays instead. Your CDN service
example has several arrays that I believe are really sets. Arrays are fine
for exchanging sets, but they make it difficult for any JSON library to
automatically create an efficient JSON Patch for the changes between
versions. For example, if the values are permuted into a different order,
the set hasn¹t changed but the array is totally different. So JSON Patch
would have to update the whole thing, as opposed to saying ³no change."
- Wendy
On 07/10/2014, 10:26, "Jan Seedorf" <[email protected]> wrote:
>Hi Wendy,
>
>What about future, new ALTO services (e.g. as proposed in
>http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-07)?
>
>I am not a fan of JSON patch, but a solution for incremental updates
>based on JSON patch should be much more future-proof with respect to new,
>future ALTO services that convey JSON objects other than network/cost
>maps, right?
>
>- Jan
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
