Wendy, Sebastian, I see your points. The thing that worries me is that one of the arguments _not_ to use ALTO for CDNI-FCI in the CDNI WG has been that it will take some time for incremental updates to be available for ALTO. We have always argued that incremental updates for ALTO are "on the way" (which indeed is/was the case). Now, from that perspective, if the "default" ALTO solution for incremental updates would only work for classic network/cost maps, and would not work for our ALTO CDNI FCI service, that is not desirable.
On the other hand, there are some differences when using ALTO for CDNI compared to P2P that have implications on incremental updates: CDNI-FCI is CDN service provider to CDN service provider (so you can expect a high capacity link between the two); the number of PIDs in a CDNI FCI network map footprint is likely much smaller than 5000; the overall size of a CDNI FCI object-format-map is likely much, much smaller than a cost map for a large ISP. All of these differences actually imply that incremental updates are not so crucial for the CDNI case than for e.g. the P2P case: if a uCDN has e.g. 4 dCDNs, the overall amount of data being sent over the network is much smaller than if an ISP has 200.000 P2P users, so fetching the complete JSON object each time may be ok for CDNI-FCI. So we may have good arguments for saying ALTO network/cost map service has a specific incr. update solution, and ALTO CDNI FCI service uses JSON patch. I guess I would like to hear other opinions ... - Jan > -----Original Message----- > From: Wendy Roome [mailto:[email protected]] > Sent: Thursday, July 10, 2014 10:21 PM > To: Jan Seedorf; IETF ALTO > Subject: Re: [alto] JSON Patch vs. custom representation for incremental > updates > > 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
