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

Re: Fixing appcache: a proposal to get us started

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 26 Mar 2013 18:58:28 -0700
Message-ID: <CA+c2ei_r90TtaD_kfrbJvWjLkHZHSrcX2-JkwCDzVPMJN6H-Rw@mail.gmail.com>
To: Rick Waldron <waldron.rick@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
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?

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

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

/ Jonas
Received on Wednesday, 27 March 2013 01:59:27 GMT

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