
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Oct 12, 2007 12:53 PM, Ian Hickson <<a href="mailto:ian@hixie.ch">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><br class="webkit-block-placeholder"></div><div>Seems like wrongly choosing one that is not actually locally available would leave a hole in your map.</div><br><blockquote type="cite"><div class="gmail_quote"><div>Or you might have a button that opens another offline application, and you want to disable the button if you think that application is not available; here a race condition would probably mean that the button is enabled but pressing it gives you an error page. In these cases isLocallyAvailable can be a useful hint even if it's occasionally wrong. <br><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.</div></div></blockquote><div><br class="webkit-block-placeholder"></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><br></div><blockquote type="cite"><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;">I'm going to punt on this for now, pending implementation and author<br>experience. I'm certainly open to suggestions though.<br><div><div></div></div></blockquote><div><br>That's fine.<br> <br>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></div></blockquote><div><br class="webkit-block-placeholder"></div><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><br class="webkit-block-placeholder"></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><br class="webkit-block-placeholder"></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><br class="webkit-block-placeholder"></div><div>Regards,</div><div>Maciej</div><div><br class="webkit-block-placeholder"></div></div></body></html>