Mark Nottingham on 01 February 2012 05:19 wrote: > On 31/01/2012, at 2:48 PM, andi abes wrote: > > > The current semantics allow you to do > > > > 1) the the most recent cached copy, using the http caching mechanism. > This will ignore any updates to the swift cluster, as long as the cache > is not stale > > > > 2) get a recent copy from swift (when setting no cache) > > > > 3) do a quorum call on all the storage nodes to get the most accurate > answer swift can provide. > > > > > > You're proposing that 2 & 3 are the same, since they're both > different than 1. But their performance implications on 2 & 3 are quite > different. > > Effectively. My point, however, is that inventing new mechanisms -- > especially new headers -- should be avoided if possible, as they > generally cause more trouble than they're worth. > > Is there really a use case for #2 being distinct from #3? > > If there is, it'd be better expressed as a new Cache-Control request > directive (e.g., Cache-Control: authoritative), next time things get > revised.
It isn't a caching directive though, it's asking for a change of behavior on the part of the swift server... _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
