Re: Fixing appcache: a proposal to get us started

[Jake Archibald]

On 26 March 2013 07:02, Jonas Sicking jo...@sicking.cc 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 seconds) we simply ignore the
 cache and load index.html and any resources it links to from the
 network.


How is online defined here? What if we're online but the page 404s, what
if we're online but DNS to that domain fails etc etc.

Offline-first isn't intuitive, I agree. I did some hacking with FALLBACK to
get online-first behaviour in Lanyrd and quickly learned why it's a bad
idea, offline performance was dire as the device had to fail to connect
before it'd show me cached data. I'd rather stick with offline-first but
present it in a way that's expected.


 If the user is offline, or if we checked for update for the appcache
 within the last 5 minutes, we use the index.html from the appcache
 without hitting the network first. If index.html uses index.js or
 index.css, those will be immediately loaded from the cache.


Is the opposite true? If index.html is loaded from the network will
index.js ever come from the cache? (current appcache says no)


 Whenever we check for updates for an appcache with the above manifest
 we do an if-modified-since/if-none-match for the manifest. We then do
 an update check for any resource requested by the manifest. I.e. even
 if the manifest hasn't changed we still do an update check for each
 resource linked to by the manifest. If any resources were added since
 the previous manifest those are obviously simply downloaded. If any
 resources were removed from the manifest those are discarded. As an
 optimization the UA can start doing update checks on the same set of
 URLs that the previous version of the manifest contained.


Don't get the last line, does the same set of URLs that the previous
version of the manifest contained mean URLs that are in the current
version, and also the previous version? Is this suggesting that obeying
HTTP cache headers is an optional optimisation?


 {
   version: 5.1,
   expiration: 300,
   cache: [index.html, index.js, index.css]
 }

 For this manifest, when we want check for update for the cache we
 first do a if-none-match/if-modified-since check for the cache object
 itself. If we get back a new resource, *and* that resource contains a
 new value for the version property, then we do update checks for all
 resources as well as download any new ones.


+1, having an explicit version property is a much better idea than the
string matching in the current manifest.


 In order to further cut down on the number of network requests, we'd
 also enable providing last-modified dates or etags directly in the
 manifest:

 {
   expiration: 300,
   cache: [{ url: index.html, etag: 84ba9f},
 { url: index.js, last-modified: Wed, 1 May 2013
 04:58:08 GMT },
 index.css]
 }


Adding these into the manifest would require some kind of automation, if
there's a level of automation couldn't it just change the url to
index.84ba9f.js and have rewriting or static generation take care of the
rest?

{
   expiration: 300,
   cache: [index.html, index.js, index.css],
   cookie-vary: uid
 }

 This would mean that even if the user is offline and navigates to
 index.html, if the value of the uid cookie is different from when
 the appcache was last updated, the appcache would not be returned. A
 UA could even use the value of the uid cookie as an additional key
 in its appcache registry and thus support keeping appcaches for
 different users on the same device.


If I have an expiration of a day, and log out as one user log in with
another, then get on a plane, none of my content would be available to me?


 The actual AppCache object has the following API:


I'm worried the API here loses the simplicity that this proposal is
supposed to have over the scripted solution, where you have to learn a
manifest format and how it interacts with items added via its scripting
API, whereas the navigation controller only has a scripting API.

Is there anything here that couldn't be done with the NavigationController
 a library? I'm not suggesting that's reason for it not to exist, just
wondering if it's offering anything unique.

Jake.

Re: [HTML Imports]: Sync, async, -ish?

[Jake Archibald]

(I'm late to this party, sorry)

I'm really fond of the link rel=import elements=x-foo, x-bar 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 article would load, the content
would be readable, then the components would appear as they load. Similar
to images without a width  height specified.

As with images, the site developer could apply styling for the component
roots before they load, to avoid/minimise the layout change as components
load. This could be visibility:hidden along with a width  height (or
aspect ratio, which I believe is coming to CSS), or display:block and
additional styles to provide a view of the data inside the component that's
good enough for a pre-enhancement render.

This gives us:

* Performance by default (we'd have made scripts async by default if we
could go back right?)
* Avoids FOUC by default
* Can be picked up by a preparser
* Appears to block rendering on pages that are build with a root web
component

Thoughts?

Cheers,
Jake.

Re: [HTML Imports]: Sync, async, -ish?

[Jake Archibald]

On 28 January 2014 18:19, Ryosuke Niwa rn...@apple.com 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.
script's default is terrible, and we're still fighting its default with
education. img's default however is pretty good.


 Isn't it better to delegate this to the component author?


Yep, you can get the blocking behaviour back. In fact, you can display:none
body until all your components are there if you want, but that's the bar
you should have to jump over to create something that results in the user
looking at a blank screen during loading.


 But that would mean that document authors need to be aware of exact
 dimensions, styles, theme, etc... of each component they use on the page,
 and add relevant CSS rules.  In addition, each component then needs to
 cancel/override those rules when they get instantiated.


Nope, in some cases appearing would be fine. In others you can reserve
space. In others you can show the inner data without interaction. If you
really must, you can show a blank screen until everything has loaded.


  * Performance by default (we'd have made scripts async by default if we
 could go back right?)
  * Avoids FOUC by default

 Could you clarify how this proposal avoids FOUC?  If unresolved elements
 were to be initially display: none and turns into display: block/inline
 later, then that would most likely cause a reflow/relayout of the page and
 causes a FOUC.


You never see a flash of unstyled content. Content is only shown once its
styles are ready.

Basically, html imports are taking cues from script, and script's default
behaviour is a mistake. If we must follow the behaviour of something
legacy, it should be img. Don't block rendering, show on load, allow the
user to do something more blocking if they must.

Re: [HTML Imports]: Sync, async, -ish?

[Jake Archibald]

:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.


On 29 January 2014 08:02, Brian Kardell bkard...@gmail.com wrote:




 On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:

 (I'm late to this party, sorry)

 I'm really fond of the link rel=import elements=x-foo, x-bar
 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 article would load, the
 content would be readable, then the components would appear as they load.
 Similar to images without a width  height specified.

 As with images, the site developer could apply styling for the component
 roots before they load, to avoid/minimise the layout change as components
 load. This could be visibility:hidden along with a width  height (or
 aspect ratio, which I believe is coming to CSS), or display:block and
 additional styles to provide a view of the data inside the component that's
 good enough for a pre-enhancement render.

 This gives us:

 * Performance by default (we'd have made scripts async by default if we
 could go back right?)
 * Avoids FOUC by default
 * Can be picked up by a preparser
 * Appears to block rendering on pages that are build with a root web
 component

 Thoughts?

 Cheers,
 Jake.


 I think that there are clearly use cases where either way feels right.
  It's considerably easier to tack on a pattern that makes async feel sync
 than the reverse.  I'd like to suggest that Jake's proposal is -almost-
 really good.  As an author, I'd be happier with the proposal if there were
 just a little bit of sugar that made it very very easy to opt in and I
 think that this lacks that only in that it relies either on a root level
 component or some script to tweak something that indicates the body
 visibility or display.  If we realize that this is going to be a common
 pattern, why not just provide the simple abstration as part of the system.
  This could be as simple as adding something to section 7.2[1] which says
 something like

 
 The :unresolved pseudoclass may also be applied to the body element.  The
 body tag is considered :unresolved until all of the elements contained in
 the original document have been resolved.  This provides authors a simple
 means to additionally manage rendering FOUC including and all the way up to
 fully delaying rendering of the page until the Custom Element dependencies
 are resolved, while still defaulting to asyc/non-blocking behavior.

 Example:
 -
 /* Apply body styles like background coloring,
 but don't render any elements until it's all ready...
 */
 body:unresolved * {
 display: none;
 }
 

 WDYT?


 [1] -
 http://w3c.github.io/webcomponents/spec/custom/#unresolved-element-pseudoclass



 --
 Brian Kardell :: @briankardell :: hitchjs.com

Re: [HTML Imports]: Sync, async, -ish?

[Jake Archibald]

My bad, many apologies. I get what you mean now.

However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine select as a built-in component which is resolved
and given a shadow DOM by internals.


On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald 
 jaffathec...@gmail.comwrote:

 :unresolved { display: none; } plus lazyload (
 https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
 would allow devs to create the non-blocking behaviour. But this is the
 wrong way around. Devs should have to opt-in to the slow thing and get the
 fast thing by default.


 Isn't that what I suggested?  I suggested that it be asyc, just as you
 said - and that all we do is add the ability to use the :unresolved pseudo
 class on the body.  This provides authors as a simple means of control for
 opting out of rendering in blocks above the level of the component without
 resorting to the need to do it via script or a root level element which
 serves no other real purpose. This level of ability seems not just simpler,
 but probably more desirable - like a lot of authors I've done a lot of work
 with things that pop into existence and cause relayout -- often the thing I
 want to block or reserve space for isn't the specific content, but a
 container or something.  Seems to me with addition of a body level
 :unresolved you could answer pretty much any use case for partial rendering
 from just dont do it all the way to screw it, the thing pops into
 existence (the later being the default) very very simply - and at the
 right layer (CSS).

Re: [HTML Imports]: Sync, async, -ish?

[Jake Archibald]

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 bkard...@gmail.com wrote:




 On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald 
 jaffathec...@gmail.comwrote:

 My bad, many apologies. I get what you mean now.

 However, if web components are explaining the platform then body is
 :resolved by browser internals (I don't know if this is how :resolved works
 currently). Eg, imagine select as a built-in component which is resolved
 and given a shadow DOM by internals.

 7.2 of custom elements states:

 
 The :unresolved pseudoclass *must* match all custom
 elements whose created callback has not yet been invoked.
 

 I suppose this leaves wiggle room that it may actually in theory match on
 native elements as well.  As you say, this is a nice explanation maybe for
 all elements - though - it doesn't seem remarkable what a custom element
 would have something a native wouldn't.  Either way, I think my proposal
 holds up in basic theory, the only caveat is whether the thing on body is
 just a specialized meaning of resolved that only applies to custom
 elements, or whether you need a specific name for that thing, right?  It's
 really entirely bikesheddable what that thing should be called or maps to -
 there must be a name for the document is done upgrading elements that we
 in the tree at parse - I dont think that is DOMContentLoaded, but
 hopefully you take my point.  If we could agree that that solution works,
 we could then have a cage match to decide on a good name :)




 On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.com
  wrote:

 :unresolved { display: none; } plus lazyload (
 https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
 would allow devs to create the non-blocking behaviour. But this is the
 wrong way around. Devs should have to opt-in to the slow thing and get the
 fast thing by default.


 Isn't that what I suggested?  I suggested that it be asyc, just as you
 said - and that all we do is add the ability to use the :unresolved pseudo
 class on the body.  This provides authors as a simple means of control for
 opting out of rendering in blocks above the level of the component without
 resorting to the need to do it via script or a root level element which
 serves no other real purpose. This level of ability seems not just simpler,
 but probably more desirable - like a lot of authors I've done a lot of work
 with things that pop into existence and cause relayout -- often the thing I
 want to block or reserve space for isn't the specific content, but a
 container or something.  Seems to me with addition of a body level
 :unresolved you could answer pretty much any use case for partial rendering
 from just dont do it all the way to screw it, the thing pops into
 existence (the later being the default) very very simply - and at the
 right layer (CSS).








 --
 Brian Kardell :: @briankardell :: hitchjs.com

Re: Fetch API

[Jake Archibald]

On 2 June 2014 00:08, Domenic Denicola dome...@domenicdenicola.com 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 for subclassing.


Agreed. So Response.redirect(url, status)?

Btw, I'd like to add similar-style factories to Response which set header 
mode defaults

Response.image(url);
Response.font(url);

etc. Don't need these for the first pass though.

Re: Fetch API

[Jake Archibald]

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 jaffathec...@gmail.com wrote:

 On 2 June 2014 00:08, Domenic Denicola dome...@domenicdenicola.com
 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 for subclassing.


 Agreed. So Response.redirect(url, status)?

 Btw, I'd like to add similar-style factories to Response which set header
  mode defaults

 Response.image(url);
 Response.font(url);

 etc. Don't need these for the first pass though.

Re: Fetch API

[Jake Archibald]

On 3 June 2014 16:50, Anne van Kesteren ann...@annevk.nl wrote:

 On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
 dome...@domenicdenicola.com 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://example.com;, {
headers: {
  X-Foo: Bar
}
  });
 
  instead of, assuming a constructor is added,
 
  fetch(http://example.com;, {
headers: new HeaderMap([
  [X-Foo, Bar]
])
  });

 Yeah, it's not clear to me what is best here. An object whose keys are
 ByteString and values are either ByteString or a sequence of
 ByteString? I agree that we want this.


I vote ByteString: ByteString. If you want something more complicated,
provide a HeaderMap or mutate after construction.

[push-api] Moving PushManager push onto ServiceWorkerRegistration

[Jake Archibald]

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(function() {
  navigator.push.register(...)
});

it'd be:

navigator.serviceWorker.ready.then(function(reg) {
  reg.push.register(...)
});

This should make it clearer that push registrations are dependent on the
serviceworker registration. Meaning each serviceworker can have its own
push registration, and unregistering a serviceworker means the push is
unregistered with it.

We're also discussing introducing
navigator.serviceWorker.getRegistration(docURL), allowing developers to get
any serviceworker registration on the origin. This means a page like
/config/ could register/unregister push for other parts of the origins
(/calendar/, /messaging/ etc).

Does that sound reasonable?

Re: [push-api] Moving PushManager push onto ServiceWorkerRegistration

[Jake Archibald]

On 11 July 2014 17:59, Jonas Sicking jo...@sicking.cc wrote:

 On Fri, Jul 11, 2014 at 8:17 AM, Jake Archibald jaffathec...@gmail.com
 wrote:
  navigator.serviceWorker.ready.then(function(reg) {
reg.push.register(...)
  });

 I agree this looks good. Though maybe

 reg.registerPush(...)

 instead?


.push also has .unregister, will probably have .hasPermission too.

(the current spec has .registrations, but I believe one registration per
serivceworker is the rule now)

Re: Push API and Service Workers

[Jake Archibald]

On 20 October 2014 03:18, Shijun Sun shij...@microsoft.com 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 practice from performance perspective,


Things I guess you'd do as a result of a push message:

* Update caches
* Show a notification
* Focus a tab  tell it to do something

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

On top of that, there are conditions that could mean I don't want to show a
notification, or hide an existing one:

* User already has relevant content focused  visible
* User reads the content elsewhere (a push message would trigger the hiding
of the current notification)

Also, if the user dismisses the notification, I may wish to send that info
back to the server, and push a message that hides the notification on other
devices. When you multiply that all together, we've got a large API, and
we've probably done the appcache thing and forgotten about particular
use-cases.

In terms of RTC, let's imagine we receive a Jeff's calling push message.
At this point I'd want to:

* If there isn't a tab open to the calling app, open one
* Else use the existing one
* Focus it (forcing it over any lock screen - we don't have a way to do
this yet)
* postMessage the page telling it who's calling
* If a call is already in progress, show a small overlay indicating the new
call, with handling options
* Else show a full screen Jeff's calling message with handling options,
play ringtone until handled

If the call is answered on a particular device, you'll want to push to
other devices to stop ringing.

That's a rough design for what I think should happen, other people may have
better ideas. I don't think now's the time to give a particular design a
high-level API. I'd rather follow the extensible web model and expose the
primitives, then build higher level bits based on common patterns that are
observed.

RE: Push API and Service Workers

[Jake Archibald]

On 21 Oct 2014 16:53, Shijun Sun shij...@microsoft.com 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 email)
 * user chooses to dismiss the notification, so not to read the email
right away

 That is it.  From the power efficiency perspective, the browser itself
doesn't have to always wake up to process the push message.  It should be a
decision by web developers whether the message should be handled explicitly
by the service worker every time it arrives.

To reiterate from my previous message:

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

Taking the email example specifically, the gmail app does the right thing.
Not only do you get a notification, but the email is also cached for
offline viewing so tapping the notification works regardless of
connectivity at moment of tapping.

This is exactly the wrong time to guess what high-level things developers
want to do and build APIs to do those imagined things.

Re: Push API change for permissions UX

[Jake Archibald]

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 owe...@google.com
wrote:
 I think it might make sense to ask for permission to display
 notifications/UI at the same time as you ask for permission to run in
the
 background.

 I hope the above explains why we believe that while some sites may want to
 ask for both permissions, they should be able to say to the user Hey, I
 want to send you notifications, without saying Hey, I want to run in the
 background whenever I want for any reason.

I suggest that if we attempt to solve this use case, that we do it by
adding the ability to send push messages that directly create a
notification, without waking up a SW.

There's recently been a separate thread about that.

/ Jonas

Re: Indexed DB + Promises

[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:

> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola  wrote:
> > This seems ... reasonable, and quite possibly the best we can do. It has
> a several notable rough edges:
> >
> > - The need to remember to use .promise, instead of just having functions
> whose return values you can await directly
>
> One way that we could solve this would be to make IDBRequest a
> thenable. I.e. put a .then() function directly on IDBRequest.
>
> > - The two-stage error paths (exceptions + rejections), necessitating
> async/await to make it palatable
>
> I'd be curious to know if, in the case of IDB, this is a problem in
> practice. I do agree that it's good for promise based APIs to only
> have one error path, but IDB is pretty conservative about when it
> throws.
>
> Do people actually wrap their IDB calls in try/catch today?
>
> Certainly throwing at all isn't perfect, but is it a big enough
> problem that it warrants using a library?
>
> > - The waitUntil/IIAFE pattern in the incrementSlowly example, instead of
> a more natural `const t = await openTransaction(); try { await
> useTransaction(t); } finally { t.close(); }` structure
>
> I'm actually quite concerned about using a t.close() pattern. It seems
> to make it very easy to end up with minor bugs which totally hang an
> application because a transaction is left open.
>
> But maybe developers prefer it strongly enough that they'll use a
> library which provides it.
>
> > I guess part of the question is, does this add enough value, or will
> authors still prefer wrapper libraries, which can afford to throw away
> backward compatibility in order to avoid these ergonomic problems?
>
> Yeah, I think this is a very good question. I personally have no idea.
>
> / Jonas
>
>

Re: Indexed DB + Promises

[Jake Archibald]

IDB already aborts the transaction if errors are thrown in callbacks.
Additionally, in the promise proposal, if the promise passed to .waitUntil
rejects, the transaction aborts. Does this address your concerns?

On Wed, 30 Sep 2015, 08:26 Conrad Irwin <conrad.ir...@gmail.com> wrote:

> One of the things I like about the WebSQL API is that the transaction
> aborts if any queries fail or if any callbacks throw errors. This way the
> whole transaction can be handled as a promise easily, which provides nice
> abstraction to the calling code.
>
> It comes at the expense of each individual operation being promisified,
> each operation still takes a callback so that you know for sure when code
> is 'done' handling a result (it's hard to tell when a promise is done
> because .then can be called multiple times and at any time).
>
> I would like to see any work on IndexedDb promises go the same way:
>
> 1. Figure out how to tell if a transaction succeeded or failed.
> 2. Wrap the transaction in a promise, so that code can be structured at a
> high level with promises.
> 3. (Optional) represent each request as a promise, if that's compatible
> 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 <jaffathec...@gmail.com>
> wrote:
>
>> 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 <jo...@sicking.cc> wrote:
>>
>>> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d...@domenic.me> wrote:
>>> > This seems ... reasonable, and quite possibly the best we can do. It
>>> has a several notable rough edges:
>>> >
>>> > - The need to remember to use .promise, instead of just having
>>> functions whose return values you can await directly
>>>
>>> One way that we could solve this would be to make IDBRequest a
>>> thenable. I.e. put a .then() function directly on IDBRequest.
>>>
>>> > - The two-stage error paths (exceptions + rejections), necessitating
>>> async/await to make it palatable
>>>
>>> I'd be curious to know if, in the case of IDB, this is a problem in
>>> practice. I do agree that it's good for promise based APIs to only
>>> have one error path, but IDB is pretty conservative about when it
>>> throws.
>>>
>>> Do people actually wrap their IDB calls in try/catch today?
>>>
>>> Certainly throwing at all isn't perfect, but is it a big enough
>>> problem that it warrants using a library?
>>>
>>> > - The waitUntil/IIAFE pattern in the incrementSlowly example, instead
>>> of a more natural `const t = await openTransaction(); try { await
>>> useTransaction(t); } finally { t.close(); }` structure
>>>
>>> I'm actually quite concerned about using a t.close() pattern. It seems
>>> to make it very easy to end up with minor bugs which totally hang an
>>> application because a transaction is left open.
>>>
>>> But maybe developers prefer it strongly enough that they'll use a
>>> library which provides it.
>>>
>>> > I guess part of the question is, does this add enough value, or will
>>> authors still prefer wrapper libraries, which can afford to throw away
>>> backward compatibility in order to avoid these ergonomic problems?
>>>
>>> Yeah, I think this is a very good question. I personally have no idea.
>>>
>>> / Jonas
>>>
>>>

Re: Indexed DB + Promises

[Jake Archibald]

On Mon, 5 Oct 2015 at 23:31 Joshua Bell <jsb...@google.com> 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 Blink
> behavior, after chewing on it for a bit. But it still seems far too subtle
> to me, and someone who writes blog posts explaining tasks vs. microtasks is
> probably not the average consumer of the API. :)
>

Step 8 of https://w3c.github.io/IndexedDB/#dom-idbdatabase-transaction can
queue a microtask to unset the active flag. It would mean:

var tx = db.transaction(…);

Promise.resolve().then(_ => {
  // transaction is now closed
});

…but if you want to keep the transaction open longer, that's what waitUntil
is for.

As for https://w3c.github.io/IndexedDB/#fire-a-success-event - this seems
fine as long as microtasks fire before step 4, which they should.

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

[Jake Archibald]

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 is it?


> Although WebApps meets on Monday and Tuesday and the IG meets on
> Thursday and Friday, if there is interest in a joint meeting, my
> understanding is that some set of IG members can meet during WebApps'
> meeting (see agenda at [3] for open slots).
>

I'm happy to attend either of IG meets, and I intend to be at the the
WebApps meeting on Monday.

Happy to meet informally too!


> Alex, Jake, Jungkee - perhaps you could meet with some of the IG members
> during the October 27 Service Worker meeting. WDYT?


I think we're already over subscribed on the 27th, would meeting on the
dates around that be enough? Happy to make time on evenings if need be.

Service worker F2F meeting - 26th Jan - San Francisco

[Jake Archibald]

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-US/contact/spaces/san-francisco/.

I've created an issue to discuss agenda items
https://github.com/slightlyoff/ServiceWorker/issues/806.

We have a couple of spaces left if you're interested in participating,
although we're going to spend the majority of the time on low-level details
and spec.

Cheers,
Jake.

Re: Service worker F2F meeting - 26th Jan - San Francisco

[Jake Archibald]

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
>> first come, first served.
>>
>
> If any are still available, I'd like to reserve one as well :)
>

Re: HTML5's Offline-first Council of Trent

[Jake Archibald]

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-cookbook/#cache-then-network).

The goal is to get cached data on screen then update it. This is because
cached data is often fine as a first pass.

If I'm going to my messaging app to remind me where I agreed to meet
someone, cached data is fine. If I'm going to my fitness app to find out
how long it took me to run two miles last week, cached data is fine. If I'm
looking up the day for my flight, cached data is fine.

But it doesn't stop there. The network is used, if available, to update
both the content on the screen (in some non-disruptive way) and in the
cache.

The benefit of having data locally on the device is you don't need an
internet connection to get it, if you refuse to show it until a network
request as settled or timed out, you're throwing away the benefit.

The offline-first pattern not only improves things for offline users, it
improves things for everyone whose connection to the internet is slower
than their device's storage.

Re: HTML5's Offline-first Council of Trent

[Jake Archibald]

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*
>
> * …*
>
> Wall Street may be closed, you could be going through the Channel Tunnel,
> or you could simply be on the dark side of the moon, but BF Day-Trader will
> let you buy or sell virtually straight from your stock portfolio!
>

I'm not a UX expert, or a trading expert (https://youtu.be/GlcuV_Dojwg),
but here's how I'd unsarcastically approach offline-first in a stocks app:

When the user revisits the site it gets to content-render before a network
response. Prior to connectivity the user can access their trading history,
and the history of entities they "follow".

As soon as cached data is displayed, the UI shows the age of the data and
something to indicate the progress of updating.

Push messages could be used to alert the user to significant changes in the
entities they follow. Once the device receives the push message the cached
data for that entity should be updated, so the full up-to-date data can be
displayed once the user taps the notification, without going to the network.

If the user attempts to make a trade prior to data updating, either
disallow it or show an appropriately severe warning.

Due to the time-sensitivity of making a trade, deferred sending via
background sync isn't appropriate. However, background sync could be used
to alert the user when they next gain connectivity, allowing them to review
changes in the market and decide if they still want to go ahead with the
trade.

Like I said in my previous post, this isn't about offline, it's about
improving the experience for everyone. And note that this isn't a choice
between cached and fresh data, it's both, you transition from one to the
other.

Re: Service Workers meeting info

[Jake Archibald]

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 meeting on 28/29 July is here:
>
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md
>
>
> If you plan to attend, it would be helpful if you could create a PR to
> add yourself to the attendees list (or let me know and I'll add you).
>
> Thanks.
> Léonie.
>
>
> It looks like the meeting info is complete on this page, except for --
> @LeonieWatson tink.uk Carpe diem
>
>