[whatwg] Caching offline Web applications

On Fri, Oct 17, 2008 at 5:36 PM, Ian Hickson <ian at hixie.ch> wrote:

>
>
>
> > - I know you added the behavior of failing loads when a URL is not in
> > the manifest based on something I said, but now that I read it, it feels
> > a bit draconian. I wish that developers could somehow easily control the
> > space of URLs they expect to be online as well as the ones they expect
> > to be offline. But maybe we should just remove the whole thing about
> > failing loads of resources not in the manifest and online whitelist for
> > v1.
>
> It seems like failing is what one wants from a debugging perspective.
>
> > Not sure the "fail if not represented in manifest" is a good idea
> > either... are there unintended consequences lurking here... what does
> > this do in the face of mashups?
>
> I'm not sure I understand; can you elaborate?
>

I was referring to the fail to load behavior discussed above. The change
such that iframes do not inherit their container's appcache alleviates my
concerns.


>
> Hmm, good point. Renamed them "master entries".


Works for me.


> > * flavors of namespaces*
> >
> >  * online whitelist
> > As mentioned in previous messages, this would need to be some form of
> > namespacing or filtering to be useful. A better term for this might be
> > 'bypass' since with respect to the appcache, hits here bypass the cache.
> Its
> > not clear if path prefix matching is the best option for filtering out
> > request that should bypass the cache. In working with app developers
> using
> > Gears, the idea of specifying a particular query argument to filter on in
> > addition to a path prefix has come up. http://server/pathprefix   +
> > &bypassAppCache
>
> I've changed it to just a prefix. Doing things at the query level seems a
> bit odd. The query parameters should be for the server, not the UA.


Agreed that query params should be for the application logic, where ever the
application logic resides:)

> * opportunistic caching namespaces
> > A mouthful but ok. Whatever terminology used for the category of
> resulting
> > entries should be used here... perhaps 'auto-caching namespace'.
>
> This is gone now.
>

Hooray


> > *Scriptlets - or dynamic namespace-handlers [new idea]*
> I haven't added this in this version.


I'm content that this idea has been injected into the
collective consciousness and am reasonably confident that sooner or later
its time will come :)

> *When is anything ever deleted?*
> >
> > Maybe i missed it, but where does appCache deletion happen?
>
> It didn't. It now does, in response to 404 or 410 statuses for manifests
> when doing an update.


> > A new type of event may be warranted for completion of such an update,
> > and when swapCache() is called there would no longer an appCache
> > associated with the context.
>
> Done.
>

Good


> > *Should we revisit the caching semantics for any resource not explicitly
> > listed in the manifest?
>
> I'm not a big fan of making these resources act differently than manifest
> resources, but I do agree that they should have different error handling.
>
> I've changed the spec so that 404 and 410 errors cause the resource to be
> removed, and other errors (and redirects) cause the resource to be copied
> from the previous cache, without the whole caching process being canceled.
>
>
Content that the bug is fixed.


> > b) Maybe there should be some way for the page to know that it was
> > loaded as a fallback.
>
> I could add something to Location, would that work?
>
>   window.location.fallbackHref
>
> ...or something? It would return the empty string unless it was a fallback
> case?


Not sure anything is needed here. If an app really needs to know this, it
could arrange such that a fallback resource should only be loaded in the
fallback case for normal application usage.


> > 2) Silent manifest parsing errors
> >
> > The spec goes out of its way to indicate that most errors while parsing
> the
> > manifest file should be silently eaten. That can't be an accident. What
> > badness is being averted by that behavior? What is trying to be
> accomplished
> > by that behavior?
>
> We want a format that is forward-compatible and convenient to use.
>
> I'm open to other syntaxes; what would you suggest?
>

This was not a comment about the file format, rather how errors in the file
are surfaced to the application.  We've seen with gears, that its easy to
introduce errors in the file (malformed urls or same-origin violations).
Wasn't thinking about forward-compatibility. The 'fail if not in cache'
semantics may help.


> 4) Why require text/cache-manifest mimetype?
> >
> > Presents a small hurdle to get over. What is being accomplished with
> > this requirement?
>
> This is actually just a restatement of HTTP's requirements. If you want
> the Content-Type to be ignored, please contact the HTTP working group and
> have them change the requirements for handling HTTP Content-Type headers.
> :-)
>

Could we specify text/plain (or text/*) as the valid content type so a
developer doesn't need access to the server infrastructure to get UAs to
accept her/his text resource as a manifest file?


> I've added an allowance for expiring resources. It's pretty open-ended,
> left up to the UA.
>

 Great

--------------------------------------------------------------------------
New topics

* Its not clear that resources add()ed around update initiation time will
make their way to a new cache that results from the update. I think the
intent is that add()ed resources will show up in the new cache regardless of
when add() is initiated or completed, but this isn't clear.

* Is it an error to initiate the add() of a resource to a cache after it has
become obsolete?

* Should there be onaddsuccess / onadderror  events that fires when add(s)
complete?

* Pseudo code omission (i think):  I don't see where the pseudo code inserts
new master entries or informs already running update of newly discovered
master entry.

* Towards the end of an update, 'candidates' are not associated with the new
cache in the upgrade attempt case. The differences between the cache attempt
vs upgrade attempt seems odd.



>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081118/4f4d2d58/attachment.htm>

Received on Tuesday, 18 November 2008 18:43:38 UTC