W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

[service-workers] SW event syntax and Cache API

From: Tobie Langel <tobie.langel@gmail.com>
Date: Thu, 3 Jul 2014 18:41:45 +0200
Message-ID: <CAMK=o4cA05Zpq1hvJo7KUUxr5Kr8yjf=zFju9G-Xv_nnV-FAMg@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, Jake Archibald <jaffathecake@gmail.com>, Alex Russell <slightlyoff@google.com>, Jungkee Song <jungkee.song@samsung.com>
Hi folks,

Couple of issues I've bumped into recently while looking at Service Workers
more closely.

1. e.respondWith + e.waitUntil.
I feel like those are strong code smells we haven't found the right design
for yet.
I have a suggestion for waitUntil[1]. None yet for respondWith, but plan to
tinker with it in the upcoming weeks. I like Anne's express.js inspired
suggestions.

2. Cache.add feels misnamed and/or heavily magic.
- I'm not sure handling atomic fetches should happen at this layer.
- Doing so shouldn't be too difficult to build given the right primitives
(fetch + Promise.all)
- It's unclear whether the promise returned by Cache.add is resolved with
responseArray or with void (WebIDL reads Promise<any>, algo doesn't mention
resolving ith responseArray). Same issue for Cache.put.

3. It should be a lot easier to prime the cache after a cache miss.
Currently the solutions I've tried are less than desirable[2]. Would like
something like this[3] to work.

Not sure what the best medium is to discuss/help with these issues. Maybe
in person?

LMK.

--tobie
---
[1]:
https://github.com/slightlyoff/ServiceWorker/issues/256#issuecomment-47878042
[2]:
https://gist.github.com/tobie/0689c5dda8f6d49d500d#file-gistfile2-js-L25-L32
[3]:
https://gist.github.com/tobie/113280d3b3db714dc199#file-gistfile1-js-L27
Received on Thursday, 3 July 2014 16:42:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC