On 22 Feb 2012, at 16:09, Martin Thomson wrote: > On 22 February 2012 07:43, Richard Alimi <[email protected]> wrote: >> Why not? Do you see cases where HTTP's notion of caching is different >> than what we want in ALTO? (Aside from the caching a part of a >> response, which Ben has already commented on above..) > > If you need to identify subsets of information, then it is quite > possible that you have too few resources in the design*. A subset > that is capable of changing could conceivably be identified as an > independent resource with independent expiration and caching. If you > want to retain the economy of a single, aggregated resource, you can > still identify portions within that resource independently. It's > possible that you would require extensions to the data format to do so > and there would be tradeoffs in complexity and (maybe) chattiness. > But you could then build on HTTP caching.
I could see how that could work, PIDs in the network map could be individual resources and the cost between a PID and other PIDs in the cost map could also be individual resources. A network or cost map could contain links to those resources or if an aggregated map is required the individual resources could be "inlined" to enable the whole map to be returned in a single response like it can today (see section 6.4.1 of draft-jenkins-cdni-metadata-00 for a description of one way we could do it and some hints about an alternative way with slightly different pros/cons). An ALTO server could then have a "change feed" resource that is akin to an Atom Feed that contains links to individual ALTO resources that have changed over time from some (specified) base map-vtag which clients could retrieve directly instead of retrieving the entire map each time. That would appear to work where it is felt acceptable to re-obtain the entire PID when any change is made to its contents (or to the cost between it and other PIDs). Clients could poll the change feed resource using HTTP's If-*-Match semantics to efficiently ensure they don't have to retrieve & process the change feed unless the network/cost maps have actually changed. Ben > > > One set of tradeoffs has already been made and that produced the > current design. That doesn't prevent a well-justified and designed > extension from functioning. There may be a case for optimization. > But there are probably better ways than inventing a protocol-specific > subscription extension. > > --Martin > > p.s. Have you looked at RFC 5989? _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
