- From: Aaron Boodman <aa@google.com>
- Date: Tue, 5 Aug 2008 23:30:23 -0700
Some quick notes/questions... - I think the manifest should be some structured, extensible format such as XML or JSON. The current text-based format is going to quickly turn into a mess as we add additional fields and rows. - I like the fallback entry feature, but I don't understand why it is coupled to opportunistic caching. On the Gears team, we frequently get requests to add a feature where a certain pattern of URLs will try to go the network first, and if that fails, will fall through to a certain cached fallback URL. But nobody has asked for a way to lazily cache URLs matching a certain pattern. Even if they had, I don't understand what that has to do with the fallback behavior. Can we split these apart, and maybe just remove the opportunistic caching thing entirely? - It seems odd that you request a resource and the server returns 400 (bad request) we fallback. Maybe it should just be up to the server to return an error message that directs the user to the fallback URL? I'm not sure about this one, looking for feedback. - Maybe this is obvious, but it's not specified what happens when the server returns a redirect for a resource that is being cached. Do we cache the redirect chain and replay it? - In practice, I expect the number of URLs in the online whitelist is going to be unbounded because of querystrings. I think if this is going to exist, it has to be a pattern. - I know you added the behavior of failing loads when a URL is not in the manifest based on something I said, but now that I read it, it feels a bit draconian. I wish that developers could somehow easily control the space of URLs they expect to be online as well as the ones they expect to be offline. But maybe we should just remove the whole thing about failing loads of resources not in the manifest and online whitelist for v1. - a
Received on Tuesday, 5 August 2008 23:30:23 UTC