Video call #1173
Comments
|
The time we're going for is Seoul/Tokyo 7AM / SF 3PM / NY 6PM / LON 11PM / SUI 12PM. Let me know which dates work for you (if you want to take part in the call) https://doodle.com/poll/9bci2wsnqr8ibyec. Update: I've reset the poll because I got the proposed dates wrong, and have worked out how to add timezone support. |
|
@jungkees @n8schloss @wanderview Apologies, I've reset the poll. Could you fill it in again? (note the dates have changed) |
|
I've updated the OP with the times and link to the meeting. |
|
Since we are only doing an hour, should we focus just on the multi-instance issue? |
|
Agreed, anything else is a bonus. |
|
I've been thinking about what we could possibly do to at least surface the fact there are multiple instances in webidl, etc. I'll try to write something up before the meeting so people can review. |
|
I started an issue on trying to represent multiple instances in the DOM. See #1185. Unfortunately there is not a really good proposal right now. |
|
It occurred to me today there are a variety of things in the Cache API we have agreed to at meetings, but I don't think are in the spec yet. We should make sure MS/webkit folks are aware of these. The meeting would be a good place to do that. |
|
I have updated the hangout link in the OP. |
|
Ali: In Edge, the "push" event goes to "background" active service worker outside of the Edge process. "notificationclick" goes to foreground in-Edge active service worker. Nate: This works fine for Facebook (#756 (comment)). Ali: "background" SW will will never see clients. But that's implementation detail. We're looking at fixing that. Alex: Why not use in-Edge SW when browser is open? Ali: Problem is if Edge closes while handling push event, that would terminate the in-Edge service worker. Jatinder: Why would you use push if a user was already on the site? Don't you have to show a notification when you receive a push? Nate: You don't if there's a window to the site open. Jake: That's in the spec. Also, getting all messages through push is good for consistency, even if page is open. Ali & Jatinder: FB case is compelling. Ben: When you postmessage to an active worker, where does it go? Ali: Foreground worker. Nate: When posting to Jatinder: Would you ever message the installing worker? Nate: We only message active right now. We have use cases for messaging others. Might experiment this week with that: installing worker messaging pages. Jake: Would you support postmessage to the background active SW? Ali: We'd support postmessaging channels. Jake: Can we just see what breaks? Edge: Ok with that. Alex: With Chrome how does this related with servisification Matt: Shouldn't affect us. We'll still have one instance. Kinuko: Agreed. All assumptions are sw is central. Edge: We only have one instance of the bg worker. Not one per push message. Andrew: What about bg sync Edge: We haven't thought that one through. Probably same as push – same "what if Edge closes" case as "push". Alex: SW can just close anyway. Edge: Better if it doesn't have to. Jake: What happens if bg active worker postmessages itself? Edge: It'd go to the background instance. Benefit of bg worker means bg work can continue. Ben: Firefox in multi process does spin up multiple instances. We pick a process and send it. Try to send to the same process. It can only see the client list in the same process, but patch landing to fix that. We're running this today – no one complaining. Just a consiquence of multi process, couldn't hold back multi process launching. Matt: In Chrome everything goes through centralised model. We ensure order between fetch and postmessage. Ordering might start changing in future. Jatinder: We'll treat this as an implementation detail. Andrew: is Edge doing shared workers? Ali: We're not looking at shared workers. Andrew: some people seem to want shared worker. Jake: Edge, any thoughts on foreign fetch. Ali: Have same concerns around double keying as Safari. We're worried about it. Jatinder: We're just looking at V1 stuff, not foreign fetch. Ali: SW is now in insiders previews in Edge. If you're interested you can test it. Andrew: Can i use VMs? Jatinder: Browserstack is free. Jake: Shall I remove foreign fetch from the specs until we figure out what we want from it? Kenji: Use-cases are stale-while-revalidate Jake: Shipping real stale-while-revalidate sounds like a better option. Ali: No objections to incubating. Jake: v1 cache stuff Jungkee: Going to make addAll resolve on body write, rather than headers right now. Jake: I feel like we should have these calls as and when we have things to discuss. Or would people prefer a regular monthly meeting? All: Nah Ben: Opaque size issue. Just be aware. Edge: We've already taken it into account. We don't have a way of estimating the quota. Ben: We have it in development. It's rounded. Ali: we should have a note in the spec about it. |
Date and time: https://doodle.com/poll/9bci2wsnqr8ibyec
Hangout https://meet.google.com/vqg-hoqa-kbz.
The meeting should last an hour.
There are one or two issues that would benefit from a few of us jumping on a call to discuss.
Some topics:
Multiple instances and scoping
#756 & #1185
Multiple service worker thread instances for the same scope/version. AIUI from the last f2f edge needs this for their push notifications integration. Safari has also indicated they would need it if they implemented. This change could be breaking given our current model and we should probably discuss if/how to adapt.
Foreign fetch
While we had previous consensus between Mozilla/Google on this API, I believe we now have some privacy concerns. In particular, there is a question of how well the feature could work given privacy models like safari's double-keying or new ITP system. There is some desire to move towards double-keying within Mozilla, so that is partly where our new concern is coming from.
Also, if we have time (but not essential):
Anything else? I'll start figuring out times & dates.
The text was updated successfully, but these errors were encountered: