[whatwg] Cache Manifest: why have NETWORK?

[Michael Nordman]

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 <michaeln at 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 <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/901a7c6a/attachment.htm>