[whatwg] Cache Manifest: why have NETWORK?

[Michael Nordman]

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 <annevk at opera.com> wrote:

> On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman <michaeln at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090924/66078b1c/attachment.htm>