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/
