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. 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
