<div dir="ltr">On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Some quick notes/questions...<br>
<br>
- I think the manifest should be some structured, extensible format<br>
such as XML or JSON. The current text-based format is going to quickly<br>
turn into a mess as we add additional fields and rows.<br>
</blockquote>
<br></div>
We've implemented the current format already in WebKit (available in nightlies and the Safari 4 Developer Preview).<br>
<br>
The format does not seem to have much call for extension and seems easy to understand and use as-is.</blockquote><div><br>I would prefer to see something more extensible, XML comes to mind. Extensibility would accommodate the addition of experimental sections and entry attributes while retaining compatibility with what has been formally adopted into the spec.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- I like the fallback entry feature, but I don't understand why it is<br>
coupled to opportunistic caching. On the Gears team, we frequently get<br>
requests to add a feature where a certain pattern of URLs will try to<br>
go the network first, and if that fails, will fall through to a<br>
certain cached fallback URL. But nobody has asked for a way to lazily<br>
cache URLs matching a certain pattern. Even if they had, I don't<br>
understand what that has to do with the fallback behavior. Can we<br>
split these apart, and maybe just remove the opportunistic caching<br>
thing entirely?<br>
</blockquote>
<br></div>
I think the idea of opportunistic caching (as I understand it) is that the author can be lazy, and not write a manifest at all.<div class="Ih2E3d"><br>
</div></blockquote><div><br>Seems like there are a few different use cases to accommodate. Spitting this up would add clarity and allow us to make indpendent decisions about  which should be in or out of the spec.<br><br>
1) Being lazy about listing images and css located in well known directories, automatically caching as the app runs.<br><br>2) Hijacking parameterized requests and returning a local resource without incurring any network traffic.<br>
<br>3) Falling back on a local resource iff server/network error.<br><br>The first item is really a convenience, the latter two are more significant features. Gears does the second one. The third item has been requested of the Gears team, but that one does present interesting versioning issues / sharp edges (not to mention implementation nightmares for extension developers).<br>
<br>What if... the server is running a newer version of the app than is currently in use... depending on type of resource it is, i think there could be some unexpected consequences, especially when you consider local SQL data with an expected schema.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
- It seems odd that you request a resource and the server returns 400<br>
(bad request) we fallback. Maybe it should just be up to the server to<br>
return an error message that directs the user to the fallback URL? I'm<br>
not sure about this one, looking for feedback.<br>
<br>
- Maybe this is obvious, but it's not specified what happens when the<br>
server returns a redirect for a resource that is being cached. Do we<br>
cache the redirect chain and replay it?<br>
<br>
- In practice, I expect the number of URLs in the online whitelist is<br>
going to be unbounded because of querystrings. I think if this is<br>
going to exist, it has to be a pattern.<br>
</blockquote>
<br></div>
I agree the online whitelist should allow patterns of some form.<div class="Ih2E3d"></div> <br></blockquote><div><br>Without the "fail if not represented in the manifest" behavior, the online whitelist may not be critical, although this idea has come up with Gears too, configuration such that...<br>
    <prefix>...&bypassAppCache=1<br>... any url of that form goes thru to the default resource loading.<br> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- I know you added the behavior of failing loads when a URL is not in<br>
the manifest based on something I said, but now that I read it, it<br>
feels a bit draconian. I wish that developers could somehow easily<br>
control the space of URLs they expect to be online as well as the ones<br>
they expect to be offline. But maybe we should just remove the whole<br>
thing about failing loads of resources not in the manifest and online<br>
whitelist for v1.<br>
</blockquote>
<br></div>
I think it would be hard to add later after the fact.</blockquote><div><br>Not sure the "fail if not represented in manifest" is a good idea either... are there unintended consequences lurking here... what does this do in the face of mashups?<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br></div>