[whatwg] Offline Web Apps

[Robert O'Callahan]

On Oct 12, 2007 9:39 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 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
> > between
> > 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.
>

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!

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.
>

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.

> 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 obvious ones.
>

Indeed.

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.

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.
>

Yes, but I think you'd want this API to be synchronous for the above
reasons.

>
> 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().
>

Agreed.

Rob
-- 
"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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071013/f6d5695b/attachment-0001.htm>