Re: Informal Service Worker working session

Thanks everyone! Started a draft agenda page here; please pile in!

https://github.com/slightlyoff/ServiceWorker/wiki/july_20_2015_meeting_agenda

On Wed, Jul 15, 2015 at 10:38 PM, Benjamin Kelly <bkelly@mozilla.com> wrote:

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