On 6/12/07, <b class="gmail_sendername">Aaron Boodman (Google)</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/11/07, Robert O'Callahan <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<br>> Chris Prince wrote:<br>> How do you do that when an ambiguity is discovered during a manifest update?
<br><br>That's a good point, i think all we could do there is throw into the<br>environment, which isn't particularly useful, but would at least<br>prevent the ambiguity.</blockquote><div><br>What do you mean "throw into the environment"? The update might occur automatically in which case I'm not sure where an exception would go. And it seems that preventing the update might lead to the app being unrecoverably "stuck".
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* Rename/copy were motivated by a particular problem we had with an<br>internal app that we were playing with. When you would capture files
<br>using the file upload api while offline, you would need to rename them<br>after you found out the primary key of the entity on the server<br>because the application would build the URIs based on these PKs. This<br>probably could have been solved other ways on the server.
</blockquote><div><br>I think the best way to handle file uploads (in an HTML5 context) is to provide an API that any Web app can use to directly read the contents of a file input control. That seems conceptually simple and also potentially useful to all kinds of Web apps, online and offline.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree that having overlapping URLs is a pain with the current<br>design. It would be nice if URLs were unique. What we found is that in
<br>many applications, URLs aren't unique. Localization is one example of<br>this, but there are many. I think it may not be necessary to have both<br>enable/disable *and* requiredCookie, but we probably need something.
<br>requiredCookie just removes some of the legwork of toggling a bunch of<br>stores on and off on each login.</blockquote><div><br>What are the other uses? Are they all situations where the content for a given URI is stable within a given "logon session"? (As you would expect if cookies are sufficient to discriminate between the different contents...)
<br><br>I think restricting URIs to map to just one resource simplifies things a lot. Another simplification that our model has is that offline resources are never directly mutated by the client; they are always just a snapshot of server state. These two properties are very appealing... We can also safely support cross-domain offline loads (
e.g. to get canonical library scripts, or looking forward to WHATWG-style messaging APIs, cross-domain communication) which I think is hard to do without the latter property.<br><br>I think we can extend our model to support Gears-style consistency without JARs by adding support for manifests somehow (
e.g. <link rel="offline-manifest">), and then requiring that all offline resources in a domain (that are used by apps in the same domain*) be updated atomically roughly the same way Gears does it. But I need to talk to Dave about it...
<br>(* Applications using cross-domain loads don't get any consistency guarantees for those loads. For example we don't want someone randomly referencing a missing file under <a href="http://example.com">example.com
</a> and breaking updates of <a href="http://example.com">example.com</a>'s own applications.)<br><br></div></div>Rob<br>-- <br>"Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more?" Simon replied, "I suppose the one who had the bigger debt canceled." "You have judged correctly," Jesus said. [Luke 7:41-43]