[whatwg] AppCache-related e-mails

On Tue, Aug 2, 2011 at 4:55 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 2 Aug 2011, Michael Nordman wrote:
> > >
> > > If you actively want to seek out old manifests, sure, but what's the
> > > use case for doing that? It would be like trying to actively evict
> > > things from HTTP caches.
> >
> > You should talk to some app developers. View source on angry birds for a
> > use case, they are doing this to get rid of stale version tied to old
> > manifest urls.
>
> But why?
>
> I couldn't figure out the use case from the source you mention.


This is a message I recently received from a different developer using the
appcache that would also like to see more in the way of being able to manage
the set of appcaches in the system. Please see the use cases listed towards
the end.


Hi Michael, Greg.  I'm writing to advise you of a requirement I'd like to
see appcache fulfill in the medium term.  We've spoken about it before, but
only in the general context of 'what would you like to see in the future'.
 No releases are gated on this feature, so I guess we're talking M15 or
thereabouts.  Feel free to cross-post this to a list you deem relevant for
wider review and discussion.

The feature is a javascript API to enable the creation, enumeration, update,
and deletion of appcaches on the current origin.  Calls might look something
like this:

/** Creates a new cache or updates an existing one with the given manifest
URL.  Manifest URL must be in the same origin as the JS */
createOrUpdateCache(String manifestUri, completionCallback, errorCallback);

/** Enumerates the caches present on the current origin */
enumerateCaches(CacheEnumerationCallback callback, ErrorCallback
errorCallback);

interface CacheEnumerationCallback {
  void handleEvent(Cache[] caches);
}

interface Cache {
  number getManifestUri();
  number getSizeInBytes();
  String getManifestAsText();
  String[] getMasterEntryUris();
  String[] getExplicitEntryUris();
  FallbackEntry[] getFallbackEntries();
  String[] getNetworkWhitelistUris();
  boolean isNetworkWhitelistOpen();
  DateTime getCreationTime();
  DateTime getLastManifestFetchTime(); // The last time the manifest was
fetched and checked for differences
  DateTime getLastUpdateTime(); // The last time a manifest fetch caused an
actual update
  DateTime getLastAccessTime(); // The last time the cache actually bound to
a browsing context
  // Maybe some APIs to signal whether the cache is currently being updated,
and whether there is currently a running browsing context bound to it.

  void delete(... some callbacks ...); // Probably fails if there's a
running browsing context bound to the cache
  void update(... some callbacks ...); // I guess a no-op if an update is
currently in progress or maybe even if it happened very recently
}

interface FallbackEntry {
  String getTriggerUri();
  String getTargetUri();
}

Additional characteristics:
* Must be usable from pages not themselves bound to an appcache, as long as
they are served from the same origin as the caches being operated on.
* Must work from workers, shared workers, and background pages, again
subject to a same origin check.

The above is a very rough sketch, and needs a bunch of work, but illustrates
the features we'd find useful.  An obvious flaw is that it doesn't fit in
with the system of progress events etc on the current API, but there are
probably many others.  View it mainly as a list of requirements.  Our use
cases are as follows:

* Docs maintains a set of appcaches which it uses for various purposes.
 Each editor, for example, has a cache.  There are also cases where
different documents require different versions of the same editor.
* The set of caches required on a particular browser depends on the
documents synced there.  A given set of documents will require a particular
(much smaller) set of caches to open.  The set of caches required on a given
browser is therefore dynamic, changing as documents enter and leave the set
of those synchronized.
* Each time anybody opens a docs property, and perhaps during the lifetimes
of some of them, we perform a procedure called 'appcache maintenance', which
ensures that the caches necessary for the current set of documents are
synced.  This is a fairly nasty process involving many iframes, but it
works.  We would like, however, to make this code much simpler, not have it
involve the iframes, and make the process of piping progress events back to
the host application less awful.  Right now it's such a pain we're not
bothering with it.
* We'd like to perform appcache maintenance on existing caches less often,
reducing server load.  The timestamps included above would allow us to do
that.
* When an appcache is no longer needed by the current set of documents, it
is currently just left there.  We would like to be able to clean it up.
* We would like to be able to perform our appcache maintenance procedure
from a shared worker, as we have one that can bring new documents into
storage.  Right now that is impossible, as I can't open an iframe there.
* When the user 'opts out' of offline, I'd like to be able to remove all
their caches.  Right now I have a process by which I can remove many of
them, but any not needed by the current set of documents will be left
behind.  We set a short-lived cookie on the domain from the client side and
then perform our usual maintenance procedure, which loads an invisible
iframe referring to each cache.  The presence of the cookie causes the
manifest fetches to serve a 404, deleting the cache.  I'd like this cleanup
to be more straightforward and for it to cover caches not needed by the
current set of documents.  I'd also like to be able to perform it without
the server - there's no inherent reason why they shouldn't be able to opt
out of offline while actually being offline.
* When a failure in the offline system is detected, or as part of manual bug
reports, I'd like to be able to send a dump of the caches currently stored
on the browser to the server, thus the APIs which interrogate the details of
the cache.
* If we ever want to migrate to an alternate architecture involving a
different use of the appcache system, this API would be invaluable for the
migration.

Received on Wednesday, 3 August 2011 18:41:09 UTC