On Oct 12, 2007 9:39 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> 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 style="">On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote:<br><div><div class="Ih2E3d"><blockquote type="cite">On Oct 12, 2007 12:53 PM, Ian Hickson <<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch
</a>> 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;"> The problem with isLocallyAvailable() -- as noted by Maciej on IRC -- is
<br>mostly one of race conditions. What if the resource was removed in between<br>you asking for it and using it? Or added?<br></blockquote><div><br> In the contexts for which it was requested, race conditions are tolerable. For example in a mapping application, if you choose the wrong tile as a template for zooming, then you get an ugly transition but that's all. 
</div></div></blockquote><div>Seems like wrongly choosing one that is not actually locally available would leave a hole in your map.</div></div><div class="Ih2E3d"></div></div></div></blockquote><div class="Ih2E3d"><br>This case was for an online app. The assumption is that either tile chosen would load "eventually"; the app would choose to base its transition effect on whichever tile was most likely to be available. I'm told that right now, they use heuristics based on a completely naive model of the browser cache!
<br><blockquote type="cite"><div class="gmail_quote"><div><blockquote>Or what if you go offline (thus<br>changing the rules) in between checking for and using the resource?<br></blockquote>That's why we have the 'whenOffline' parameter.
<br></div></div></blockquote></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div>I don't see how the whenOffline parameter addresses that problem that your online/offline state may change between the time you do the check and the time you try to load the resource. In fact, I'm not really sure how it is helpful, compared to just basing the check on the current online/offline state always.
</div><div class="Ih2E3d"><div></div></div></div></div></blockquote><div> <br>Some apps may find it helpful to be able to predict their offline capabilities even while they're online. For example, an app might want to indicate what the user will be able to do if they go offline right now.
<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 style=""><div><div class="Ih2E3d"><blockquote type="cite"><div class="gmail_quote">
A race-free API seems difficult to design. Because loads are typically asynchronous, I doubt you can do much better than start a regular load, and set a timer to go off and cancel the load and take other action if the load doesn't complete "fast enough".
</div></blockquote><div>The race-free approach would be to provide APIs to load resources only from the cache and to error out immediately if the the request can't be served locally. The problem with this is that there are a huge number of APIs to trigger a load: frame src, iframe src, 
window.location assignment, window.location.replace, img src, script src, link for a stylesheet, XMLHttpRequest, and that's just the obvious ones.</div></div></div></div></blockquote><div><br>Indeed.<br><br>Another problem is that if you want to offer a hard guarantee that the resource will load, you probably want to check not just whether it's in the cache but also that no other error will occur before the load completes (
e.g. due to a change in the browser state during a load). This might be simple, or it might not, depending on the browser implementation. In other words, the race window doesn't end when the load starts, it actually ends when the load ends IMHO.
<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 style=""><div><div class="Ih2E3d"><div></div></div><div>I think a way to do an XMLHttpRequest that will only succeed if the data is cached would cover many cases, and is probably a reasonable extension to XHR (given the text of an html document, script or stylesheet, you can insert it into an appropriate element for use). The problem is binary formats, since XHR has no good way of returning the data yet and the elements that would consume them (img, video, audio, object) have no way to pass in raw bytes (using a data: URL to encode it would be poor form for image and probably unworkable for video). However, if those elements were extended with some way to set raw data then such an approach could work.
</div></div></div></blockquote><div><br>Yes, but I think you'd want this API to be synchronous for the above reasons.<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 style=""><div><div></div><div><br></div><div>At that point, isLocallyAvailable might possibly be useful solely as a UI hint, much as the POSIX access() / stat() calls are only useful as UI hints for openability. In fact, this is pretty much analogous to the potential pitfalls of access() vs. open(). You need to check whether open() succeeds, and pass it the right parameters to make sure it will fail if it shouldn't succeed, rather than trusting a pre-check with access() or stat().
</div><div></div></div></div></blockquote><div><br>Agreed.<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]