Re: [whatwg] Cache Manifest: why have NETWORK?
On Thu, 24 Sep 2009 10:43:57 +0200, 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=xnewValue=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. If this change is not made (though I hope it will, since it makes sense) the specification should make it more clear in the writing section (and maybe in parsing too) of the manifest that having both a wildcard and some network URLs does not make sense as the wildcard will always win anyway (per the changes to the networking model section). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Cache Manifest: why have NETWORK?
On Thu, 24 Sep 2009 22:49:51 +0200, Michael Nordman micha...@google.com wrote: 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? It seems quite natural to specify a catch-all fallback namespace and still want some resources to hit the network. I.e., as I demonstrated with an example: FALLBACK: / /offline NETWORK: /request Now Ian suggested I could instead do FALLBACK: /request /request?fallback /offline ... which could certainly work but would make NETWORK redundant. You argued however that NETWORK was needed because a fallback resource with a mock error or empty response is busy work While I did not quite understand this reason I suppose having the additional fallback while a network error should be sufficient is not great and therefore I suggested giving non-wildcard NETWORK resources priority. You suggest this might make sense, but I've yet to see a good argument as to why the current approach makes sense. It certainly does not help with the example above. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Cache Manifest: why have NETWORK?
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=xnewValue=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/
Re: [whatwg] Cache Manifest: why have NETWORK?
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=xnewValue=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/
Re: [whatwg] Cache Manifest: why have NETWORK?
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.comwrote: 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.comwrote: 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=xnewValue=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/
[whatwg] Cache Manifest: why have NETWORK?
If you use a fallback namespace it will always try to do a network fetch before using the fallback entry so why is there a need for a NETWORK entry in the cache manifest? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Cache Manifest: why have NETWORK?
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=xnewValue=y Ditto On Wed, Sep 23, 2009 at 2:47 AM, Anne van Kesteren ann...@opera.com wrote: If you use a fallback namespace it will always try to do a network fetch before using the fallback entry so why is there a need for a NETWORK entry in the cache manifest? -- Anne van Kesteren http://annevankesteren.nl/
