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 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
Re: Informal Service Worker working session
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
Informal Service Worker working session
Hey all, Apologies for the late notice. 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 Regards
