W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Fixing appcache: a proposal to get us started

From: Rick Waldron <waldron.rick@gmail.com>
Date: Tue, 26 Mar 2013 21:28:33 -0400
Message-ID: <CAHfnhfqGbfrqBomwbq5KdWpP81uu9tPMWVHj2kibu0SXWnUTuA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.


On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> (snip)
>
> First we need a way to get at AppCache objects:
>

No mention of installAppCache, removeAppCache or getAppCacheList anywhere
else in the email—not even to say they are in progress?


>
> partial interface Navigator {
>   Future<AppCache> installAppCache(url);
>   Future<AppCache> getAppCache(url);
>   Future<boolean> removeAppCache(url);
>   Future<DOMString[]> getAppCacheList();
> }
>

There is no way to create an alias binding for shortening these calls—the
kids love shorthanding ;)

This isn't really a navigator capability is it? Perhaps instead of adding
surface to navigator, a new global called "platform", for platform related
APIs that aren't quite navigator, document or window (?) capabilities...


  partial interface Window {
    Object platform
  }

  partial interface platform {
    Object appCache
  }

  interface appCache {
    Future<AppCache> install(url);
    Future<AppCache> get(url);
    Future<boolean> remove(url);
    Future<DOMString[]> list();
  }


If that's not desirable (which I can easily understand), then dump it on
the window. Yes, it stinks to put more "things" on the window object, but
developers understand recognize the pattern (it's also minifier friendly)

  partial interface Window {
    Object appCache
  }

  interface appCache {
    Future<AppCache> install(url);
    Future<AppCache> get(url);
    Future<boolean> remove(url);
    Future<DOMString[]> list();
  }


With this API surface, the code I might ship:

  (function(window) {
    var appCache = window.appCache;
    appCache.get("url a").then(function(cache) {
      // do stuff and things...
    });
    appCache.remove("url b").then(function(cache) {
      // do stuff and things...
    });
  }(this));


Minifies to:

  (function(a){var b=a.appCache;b.get("url
a").then(function(){}),b.remove("url b").then(function(){})})(this);


vs. the proposed API:

  (function(window) {
    var navigator = window.navigator;
    navigator.getAppCache("url a").then(function(cache) {
      // do stuff and things...
    });
    navigator.removeAppCache("url b").then(function(cache) {
      // do stuff and things...
    });
  }(this));

  (function(a){var b=a.navigator;b.getAppCache("url
a").then(function(){}),b.removeAppCache("url b").then(function(){})})(this);



Specifically, the interesting parts are:

  b.get("url a").then(function(){}),b.remove("url b").then(function(){})
  b.getAppCache("url a").then(function(){}),b.removeAppCache("url
b").then(function(){})





>
> partial interface Document {
>   AppCache appCache;
>   readonly attribute boolean appCacheUpdateAvailable;
>   attribute EventHandler onappcacheupdateavailable;
> }
>

As an author, I would already know that I'm working with an "appCache"
object, therefore the word "appCache" prefix on the boolean property is
just junk that's not "minifiable". So...

appCacheUpdateAvailable =>
  - updateAvailable
  - hasUpdate
  - isAvailable
  - ?

Anyway, great work from all involved. I'm excited to see such momentum and
dedication to getting app cache back on track :)

Rick


>
> snip
>


>  / Jonas
>
>
Received on Wednesday, 27 March 2013 01:29:36 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 01:29:36 GMT