I probably should've held the semantics of NETWORK constant in my earlier notes, and alluded to a new FALLTHRU section that has the *this section gets examined first* characteristic... same thing with the names changed to protect the innocent bystanders (those using NETWORK namespaces already).
On Thu, Sep 24, 2009 at 1:49 PM, Michael Nordman <micha...@google.com>wrote: > 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... > if (url is CACHED) > return cached_resposne; > if (url has FALLBACK) > return > repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response; > if (url is in NETWORK namespace) > return response_as_usual; > otherwise > return synthesized_error_response; > > Sounds like you may be warming up to make a case for something like... > > if (url is in NETWORK namespace) > return response_as_usual; > if (url is CACHED) > return cached_resposne; > if (url has FALLBACK) > return > repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response; > otherwise > return synthesized_error_response; > > 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... > > if (url is in NETWORK namespace) > return response_as_usual; > if (url is CACHED) > return cached_resposne; > if (url has FALLBACK) > return > repsonse_as_usual_unless_for_fallback_conditions_are_met_by_that_response; > if (url is in FALLTHRU namespace) > return response_as_usual; > otherwise > return synthesized_error_response; > > Notice the distinction between NETWORK vs FALLTHRU both of which hit the > wire. > > Cheers > > > > On Thu, Sep 24, 2009 at 1:43 AM, Anne van Kesteren <ann...@opera.com>wrote: > >> On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman <micha...@google.com> >> wrote: >> >>> For cases where you don't want to, or can't, 'fallback' on a cached >>> resource. >>> ex 1. >>> >>> http://server/get/realtime/results/from/the/outside/worldCreating a >>> fallback >>> resource with a mock error or empty response is busy work. >>> >>> ex 2. >>> >>> http://server/change/some/state/on/server/side?id=x&newValue=y >>> Ditto >>> >> >> 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 >> >> FALLBACK: >> / /fallback >> >> NETWORK >> /realtime-api >> /update >> >> ... you do not get /fallback all the time. >> >> >> >> -- >> Anne van Kesteren >> http://annevankesteren.nl/ >> > >
