Re: Informal Service Worker working session

On Sat, Jul 4, 2015 at 7:26 AM, Alex Russell <slightlyoff@google.com> wrote:

> As many SW participants are going to be in town for the WebApps F2F on the
> 21st, Google San Francisco is hosting a working day, 9am-5pm PST on July
> 20th to work through open issues and discuss future work.
>
> If you're attending, or would like to, simply RSVP here:
> http://doodle.com/hqm3ga8pfepidy7r
>

Alex,

Thanks for hosting!

In preparation for the meeting we've come up with a rough list of things
we'd like to discuss next week:

 - Clarify behavior in places where the fetch spec has not been integrated
into other specs yet.  For example, intercepting something that is
currently same-origin with a synthetic or CORS response, how interception
works with CSP, etc.  Clearly Chrome has done something for these cases and
we'd like to be compatible where possible.
 - Consider adding a "foreign fetch" feature to communicate with a SW on a
different origin.  Straw man of the concept can be found at
https://wiki.whatwg.org/wiki/Foreign_Fetch .
 - Discuss navigator.connect().  In particular, can the use cases
motivating navigator.connect() be satisfied with a simpler solution like
the "foreign fetch" concept.
 - Discuss how to make it easier to use multiple service workers for the
same site.  For example, currently its difficult to update two service
workers coherently.  One will always be a newer version than the other.
 - Discuss how to handle heavy-weight processing for things like background
sync without introducing fetch event latency.  This could be using multiple
service workers (with issues above addressed) or possible supporting
SharedWorker, etc.
 - Consider using the service worker script URL to identify the service
worker instead of its scope.  This would move us closer to not requiring a
scope for service workers that aren't handling fetch events.
 - Consider allowing specific features, like fetch and push, to be
specified at registration time.  Again, the goal is to get away from the
current situation where registering a service worker immediately implies
fetch event handling.
 - Consider providing an API for creating a service worker without going
through the installation life cycle.
 - Share information about how we plan to avoid abuse of push and
background sync events.

Anyway, we just wanted to give people a chance to think about some of this
before we meet.  Obviously we may not have time to cover all of this in a
day, but it would be nice to cover any contentious bits.

Thanks again and see you all next week.

Ben