RE: PSA: publishing new WD of Service Workers on June 25

Thanks for comments. I'll address them in the ED.

I didn't get through them all yet, but

> * in parallel isn't defined, but it sounds like you mean "in parallel to the main sequence" not "in parallel to themselves", I'd strongly encourage a definition.

"in parallel" is defined here: https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel. Will add the links.


Jungkee

> -----Original Message-----
> From: timeless [mailto:timeless@gmail.com]
> Sent: Wednesday, July 01, 2015 1:23 PM
> To: public-webapps
> Subject: Re: PSA: publishing new WD of Service Workers on June 25
> 
> http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-
> service-workers-20150625/
> 
> >     Invoke Run Service Worker algorithm with serviceWorker as the
> arguement [sic].
> > Fetch invokes Handle Fetch with request. As a result of performing
> Handle Fetch, the Service Woker [sic] returns a response to Fetch.
> >    If the client request is under the scope of a service worker
> registration, appplication [sic] cache is completely bypassed regardless
> of whether the client request uses the service worker registration.
> 
> > Events that correspond to network requests are dispatched to the worker
> and the responses generated by the worker may over-ride* default network
> stack behavior.
> 
> override
> 
> en-us:
> >        Let the origin attribute of e be initialized to the Unicode
> serialisation* of the origin specified by the incumbent settings object.
> > Service workers define the following behaviours* for install event and
> activate event:
> 
> 
> > When a service worker client is controlled by an active worker, it is
> considered the service worker client is using the active worker's
> containing service worker registration.
> 
> 
> this is awkward, you might add `that` after `it is`
> 
> 
> > This is conceptually the same operation that UA does maximum once per
> every 24 hours.
> 
> this is awkward, you might add `the` before `UA`, `a` after `does` and
> `of` before `once`.
> 
> > Run the following substeps in parallel:
> > 1. CheckRegistration: If the result of running Match Service Worker
> Registration algorithm, or its equivalent, with clientURL as its argument
> is not null, then:
> > 1.1. Set registration to the result value.
> > 2. Else:
> 
> Else seems odd for `run...in parallel`
> 
> > 2.1. Wait until scope to registration map has a new entry.
> > 2.2. Jump to the step labeled CheckRegistration.
> 
> cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ...
> /;s/.*( run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/> /'|sort|uniq -
> c|sort
> -n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/'
> > Return the ... handler ... performs the following substeps in
> > parallel: [1] Return the ... handler that performs the following
> > substeps in parallel: [1] Run the following in parallel: [1] Set p to
> > the ... handler that ... performs the following substeps in parallel:
> > [1] run the following substeps in parallel: [1] Return the ... handler
> > that ... performs the following substeps in parallel: [4] run the
> > following substeps in parallel. [4] Run these steps in parallel: [7]
> > Run the following substeps in parallel: [10]
> 
> * you use <steps|substeps> interchangeably afaict; you sometimes don't use
> *steps...
> * you use <.|:> interchangeably
> * various other inconsistent stylistic elements can be seen from the above
> list...
> * in parallel isn't defined, but it sounds like you mean "in parallel to
> the main sequence" not "in parallel to themselves", I'd strongly encourage
> a definition.
> 
> > The following are the event handlers (and its corresponding event
> > handler event types) that must be supported,
> 
> pattern:
> event handlers [plural!] (and its ...)
> its => their
> 
> > The service worker registration's installing worker changes. (See step 8
> of the Install algorithm).
> > A WindowClient object has an associated focus state, which is either
> true or false. (Initially false).
> 
> pattern:
> misplaced `.`
> 
> > When event.respondWith(r) method is invoked, the argument, r, must
> resolve with a Response, else a network error is returned to Fetch.
> 
> `must .. else` is an odd construct. normally `or` is appropriate...
> 
> > The Cache objects do not expire unless authors delete the entries.
> 
> `objects ... the entries` is odd
> 
> the entries => them | objects => object entries ??
> 
> > This implies that authors should version their caches by name and make
> sure to **use the caches only from the version of the service worker that
> can safely operate on**.
> 
> ... => to only use caches that can be safely operated by the current
> version of the service worker.
> 
> > Cache objects are always enumerable via self.caches in insertion order
> > (per ECMAScript 6 Map objects.) Resolve p with the result of running
> > the algorithm specified in match(request, options) method of Cache
> > interface with request and options as the arguments (providing
> > entry.[[value]] as thisArgument to the [[Call]] internal method of
> > match(request, options).)
> 
> pattern:
> misplaced `.` (the other way...)
> 
> 
> > If r's method is neither `GET` nor `HEAD` and options.ignoreMethod is
> false, resolve promise with an empty array.
> > If options.ignoreMethod is false and request.method is neither "GET" nor
> "HEAD", then:
> 
> you usually use ``s instead of ""s around GET/HEAD, which I found weird,
> but here you didn't do that, which I find even weirder...

Received on Wednesday, 1 July 2015 11:51:38 UTC