RE: consequences of hashes controlling cache refresh
"Larry Masinter" <[email protected]>
| Newsgroups | gmane.ietf.medfree |
|---|---|
| Message-ID | <[email protected]> |
> Since > I use CONNEG indirection to propagate changes in corporate policy, This is an unreasonable application of CONNEG indirection. The purpose of the syntax is to represent the capabilities of a recipient. It sounds like you're trying to use indirection to solve a very different problem than the one initially proposed, which is to compactly represent what otherwise would be a large capability expression. It sounds like your goal is to reflect a centralized policy maintained by a policy service, in a regime where the content server obtains the policy from the centralized policy service but the client does not! If this is really what you want to do, then the hash isn't needed at all, you just want the URL. However, it's a little odd to posit that the client doesn't actually find out the capabilities that it's requesting! It would seem more reasonable, in your scenario, for the client to retrieve the policy with whatever frequency the client wants (from the central policy server) and then send the hash of the actual policy it knows about. It's unreasonable to expect that a mobile device would ask for a set of capabilities without actually knowing what they are. -------------- > I figure that I don't need to update the mobile devices, only > the contents of the resource stored at the URL. > > As in my original message, I see two possible modes for using hashes > as abbreviations in content negotiation: > (1) Every time one of my company's devices opens negotiation, > it sends both the hash and the URL. In that case, after > my birthday, my mobile devices keep sending in the hash > code 0x1234, and the URL. The servers could check the URL, > but they don't, because they use the hash value to decide > when a cache refresh is needed, and the hash value > hasn't change. So they continue to use paper-size=letter. > (2) Every time one of my company's devices opens negotiation, > it sends only the hash. Again, after the changeover, the > devices still send the hash code 0x1234, and the servers > fetch the old paper-size=letter properties from their > caches and use that. > Given that you want to use hash values to force cache refresh > exactly when needed so that there don't need to be cache timeouts, > it seems to me that unless you modify the hash values stored in > every individual client device, you will end up with stale hash > values being used to retrieve stale cached values, not the true > indirection which is needed in order to centrally control policy. > > Bill Newman > [email protected] >