Re: Fixing appcache: a proposal to get us started

On Tue, Mar 26, 2013 at 9:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Mar 26, 2013 at 6:28 PM, Rick Waldron <waldron.rick@gmail.com>
> wrote:
> > This is a lot to digest, but I know the developer community will greatly
> > appreciate the work that has gone into this—thank you.
>
> Yeah, I hope this is possible to consume despite its length. I'll
> create a shorter writeup with less background for the next iteration.


> > 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?
>
> Sorry, i missed this. I hope they are generally pretty obvious what
> they do on a high level though?
>

Yes, they are—you were so thorough that their absence was alarming ;)


>
> >> 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...
>
> Yeah, I wasn't sure what to do about this. I'm not really exited about
> adding a property to the global object which has a name that is as
> generic as "platform".
>
> >   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();
> >   }
>
> I like this general approach other than the issue mentioned above.
>
> > 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();
> >   }
>
> This might be more ok. As would sticking the appCache property on the
> navigator object be.
>
> >> 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".
>
> The "updateAvailable" isn't really a property of the AppCache object
> though. An appcache is updated as soon as it has been downloaded. It's
> the view that the user is currently looking at that is out-of-date.
>

Yep, I misread that—thanks for clarifying.

>
> Possibly if we add a appCache property on window or navigator then
> putting the property there might work.
>

Even better :)


> / Jonas
>