The relative priorities of FALLBACK vs CACHED vs NETWORK are somewhat arbitrary, it has to be spelled out in the spec, but how they should be spelled out is anybody's guess. The current draft puts a stake in the ground in section 6.9.7 (and also around where frame navigations are spelled out) such that...<div>
<br></div><div>if (url is CACHED)</div><div>  return cached_resposne;</div><div>if (url has FALLBACK)</div><div>  return repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response;</div><div>if (url is in NETWORK namespace)</div>
<div>  return response_as_usual;</div><div>otherwise</div><div>  return synthesized_error_response;</div><div><br></div><div>Sounds like you may be warming up to make a case for something like...</div><div><br></div><div>
<div>if (url is in NETWORK namespace)</div><div>  return response_as_usual;</div><div>if (url is CACHED)</div><div>  return cached_resposne;</div><div>if (url has FALLBACK)</div><div>  return repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response;</div>
<div>otherwise</div><div>  return synthesized_error_response;</div><div><br></div></div><div>That probably makes sense too in some use cases. Without practical experience with this thing, its difficult to 'guess' which is of more use. Really these aren't mutually exclusive at all...</div>
<div><br></div><div><div>if (url is in NETWORK namespace)</div><div>  return response_as_usual;</div><div>if (url is CACHED)</div><div>  return cached_resposne;</div><div>if (url has FALLBACK)</div><div>  return repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response;</div>
<div>if (url is in FALLTHRU namespace)</div><div>  return response_as_usual;</div><div>otherwise</div><div>  return synthesized_error_response;</div><div><br></div></div><div>Notice the distinction between NETWORK vs FALLTHRU both of which hit the wire.</div>
<div><br></div><div>Cheers</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Thu, Sep 24, 2009 at 1:43 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman <<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
For cases where you don't want to, or can't,  'fallback' on a cached<br>
resource.<br>
ex 1.<br>
<br>
</div><a href="http://server/get/realtime/results/from/the/outside/worldCreating" target="_blank">http://server/get/realtime/results/from/the/outside/worldCreating</a> a fallback<div class="im"><br>
resource with a mock error or empty response is busy work.<br>
<br>
ex 2.<br>
<br>
<a href="http://server/change/some/state/on/server/side?id=x&newValue=y" target="_blank">http://server/change/some/state/on/server/side?id=x&newValue=y</a><br>
Ditto<br>
</div></blockquote>
<br>
You could fallback to a non-existing fallback or some such. But if it is really needed NETWORK should get priority over FALLBACK in my opinion (or at least the subset of NETWORK that is not a wildcard) so in cases like this<br>

<br>
  FALLBACK:<br>
  / /fallback<br>
<br>
  NETWORK<br>
  /realtime-api<br>
  /update<br>
<br>
... you do not get /fallback all the time.<div><div></div><div class="h5"><br>
<br>
<br>
-- <br>
Anne van Kesteren<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</div></div></blockquote></div><br></div>