[whatwg] Offline Web Apps

[Maciej Stachowiak]

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.

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

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

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071012/8a8a1e78/attachment-0001.htm>