[whatwg] Offline Web Apps
mjs at apple.com
Fri Oct 12 01:39:25 PDT 2007
On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote:
> On Oct 12, 2007 12:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> The problem with isLocallyAvailable() -- as noted by Maciej on IRC
> -- is
> mostly one of race conditions. What if the resource was removed in
> you asking for it and using it? Or added?
> 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.
Seems like wrongly choosing one that is not actually locally available
would leave a hole in your map.
> 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.
> Or what if you go offline (thus
> changing the rules) in between checking for and using the resource?
> That's why we have the 'whenOffline' parameter.
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.
> I'm going to punt on this for now, pending implementation and author
> experience. I'm certainly open to suggestions though.
> That's fine.
> 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".
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
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.
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().
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg