Open Stack

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.