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 <bke...@mozilla.com> wrote: > On Sat, Jul 4, 2015 at 7:26 AM, Alex Russell <slightly...@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 >