Mark Nottingham 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. >Anyway, not a big deal, as it's already out there. On a purely functional analysis you are correct. But my preferences in API design are that options are to be used for things that are optional. A distinct function, like check for most recent version, Should be a distinct command. Otherwise the verb ends up being meaningless and the options become the real verb. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
