Notes were taken in IRC, here's a log
https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. Here's
my run-down of the headlines
https://jakearchibald.com/2016/service-worker-meeting-notes/.
On Tue, 12 Jul 2016 at 11:52 Léonie Watson wrote:
> Hello WP,
>
> Information for the me
On Wed, 16 Mar 2016, 04:46 Richard Maher, wrote:
> Look Jake, your entire argument is premised on the abstract notion that
> “cached
> data is often fine”. Allow me to respond with an equally unquantifiable
> “EXCEPT WHEN IT BLOODY ISN’T”.
>
> ...
>
> *The Bud Fox Day-Trader App*
>
> * …*
>
> W
On Tue, 15 Mar 2016 at 12:14 Richard Maher wrote:
> Your willingness, nay preference, to serve up stale, outdated data, is an
> exercise in self-flagellation that only a fellow sicko could understand
>
This is not the intent in the pattern you quote (
https://jakearchibald.com/2014/offline-cookbo
Updated https://github.com/slightlyoff/ServiceWorker/issues/806 with
attendees, including Ilya & Conrad.
On Tue, 5 Jan 2016 at 00:27 Ilya Grigorik wrote:
>
> On Mon, Jan 4, 2016 at 9:12 AM, Anne van Kesteren
> wrote:
>
>> We have three more seats at this point, allocated on the basis of
>> firs
Since many of those involved in service workers will be in town for the web
components meeting on the 25th (
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md)
we're having a service workers meeting on the 26th.
The meeting is being hosted by Mozilla
https://www.mozilla.org/en
On Mon, 5 Oct 2015 at 23:31 Joshua Bell wrote:
> Yeah - "When control is returned to the event loop" isn't precise enough.
> It's an open issue in the 2nd Ed. and I welcome suggestions for tightening
> it up. Note that Jake Archibald, at least, was happy with the Bl
On Mon, 5 Oct 2015 at 13:00 Arthur Barstow wrote:
> The IG welcomes discussion and feedback during their October 19
> conference call (if interested, please contact Tzviya) and/or during
> TPAC.
I'm happy to take part in this from a service worker point of view, if
timezones add up. What time i
gt; with goal 1.
>
> If I remember rightly it's hard to do 1 in general with the current
> non-promise based API, so any change to make the API more promise
> based should first address that.
>
> Conrad
>
>
>
>
> On Tuesday, September 29, 2015, Jake Archibald
&
I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be
thenables. This could be done by having a hidden promise, and having
.then/.catch proxy to the same methods on the hidden promise.
We just have to get over the throw/reject thing.
On Tue, 29 Sep 2015, 23:16 Jonas Sicking wrote:
Example https://www.youtube.com/watch?v=0i7YdSEQI1w - Twitter shows
notifications without caching, creating a poor offline (or poor
connectivity) experience. You can actually be left with less information
after tapping the notification than before.
On 26 October 2014 06:42, Jake Archibald wrote
This discussion is about how often push may be processed silently (without
showing a notification), not if a push notification may *only* show a
notification.
The latter was shown to be insufficient in the other thread.
On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore
wrote:
>> I think it mig
On 21 Oct 2014 16:53, "Shijun Sun" wrote:
>
> On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote:
> >Things I guess you'd do as a result of a push message:
>
> One of the most typical scenarios is
> * show a toast notification (e.g. for a new em
On 20 October 2014 03:18, Shijun Sun wrote:
> What I'd like to get across is when the "push client" can handle generic
> actions already, such as posting a toast notifications, waking up the
> browser (or a subset of it) and let service workers to display each
> notification might not be the best
On 11 July 2014 17:59, Jonas Sicking wrote:
> On Fri, Jul 11, 2014 at 8:17 AM, Jake Archibald
> wrote:
> > navigator.serviceWorker.ready.then(function(reg) {
> > reg.push.register(...)
> > });
>
> I agree this looks good. Though maybe
>
> reg.registerPush
Currently serviceworker-dependent APIs are sitting in navigator.whatever,
but now we're adding a ServiceWorkerRegistration object (
https://github.com/slightlyoff/ServiceWorker/issues/365#issue-3745) it
feels like they should live there.
So instead of:
navigator.serviceWorker.ready.then(funct
On 3 June 2014 16:50, Anne van Kesteren wrote:
> On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
> wrote:
>
> - I like HeaderMap a lot, but for construction purposes, I wonder if a
> shorthand for the usual case could be provided. E.g. it would be nice to be
> able to do
> >
> > fetch("http://e
Ugh, I meant "Request" for a lot of that:
I'd like to add similar-style factories to *Request* which set header &
mode defaults
Request.image(url);
Request.font(url);
etc. Don't need these for the first pass though.
On 3 June 2014 14:01, Jake Archibald wrote:
> On
On 2 June 2014 00:08, Domenic Denicola wrote:
>
> > Presumably RedirectResponse being a subtype would also be acceptable, as
> its .prototype.constructor would be RedirectResponse?
>
> Yeah, although I'm not sure there's a need to override any functionality
> here, so not sure that there's a need
I'm not excited about making render blocking easier, but I think you're
right.
However, this is all premature detail while the behaviour is blocking-first.
On 29 January 2014 09:53, Brian Kardell wrote:
>
>
>
> On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald
>
On 29 January 2014 09:19, Brian Kardell wrote:
> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
> wrote:
>
>> :unresolved { display: none; } plus "lazyload" (
>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
&
t the
fast thing by default.
On 29 January 2014 08:02, Brian Kardell wrote:
>
>
>
> On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald wrote:
>
>> (I'm late to this party, sorry)
>>
>> I'm really fond of the
>> pattern, but I yeah, you could end u
On 28 January 2014 18:19, Ryosuke Niwa wrote:
>
> > How about making link[rel=import] async by default, but make elements
> with a dash in the tagname display:none by default?
> Is it really the right thing to do in all cases?
Nope, but no default is. The default shouldn't be slow for the user.
(I'm late to this party, sorry)
I'm really fond of the pattern,
but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements with
a dash in the tagname display:none by default?
On a news article with components, the news articl
On 26 March 2013 07:02, Jonas Sicking wrote:
> {
> "expiration": 300,
> "cache": ["index.html", "index.js", "index.css"]
> }
>
> If the user navigates to index.html The following happens:
>
> If the user is online and we haven't checked for update for the
> appcache in the last 5 minutes (300
24 matches
Mail list logo
