| 01:07 | <MikeSmith> | agio: https://tools.ietf.org/html/rfc2046#section-4.5 |
| 01:08 | <MikeSmith> | > The "application" media type is to be used for discrete data which do not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user. |
| 01:08 | <agio> | thanks, I found that too |
| 13:26 | <annevk> | gsnedders: re https://twitter.com/gsnedders/status/1067042972594855936 isn't Map preferable since you cannot get confused by other properties existing, e.g., someone doing __proto__ or some such |
| 13:30 | <gsnedders> | annevk: __proto__'s setter is on Object.prototype nowadays, no? So given a null [[Prototype]] there should be no magic? |
| 13:30 | <gsnedders> | Like, I'm pretty sure __proto__ isn't special-cased in [[Set]] nowadays |
| 16:06 | <annevk> | Domenic: so anywhere else you argue for mostly explicit management of things, and we also have construction and destruction of realms mostly defined, but agents is too far and needs to be circular? (In a way I'm not at all convinced actually works. In fact I'm pretty certain it doesn't.) |
| 16:07 | <annevk> | I'd rather have the most basic building blocks rather explicitly defined. If we do our job well there also wouldn't be too much management of them throughout the standards... |
| 16:07 | <Domenic> | annevk: You're right in this case, and I'm writing up why. But in general I much prefer simple definitions based on the properties of an object, over manually adding and removing things to a collection |
| 16:08 | <Domenic> | Layered != circular |
| 16:08 | <annevk> | But this isn't properly layered |
| 16:08 | <annevk> | Realms have origins, browsing contexts don't |
| 16:08 | <Domenic> | It has bugs, and ones that are unfixable (as I'm writing up). But fundamentally there's no difference between layering agents on top of URSOBCs versus layering URSOBCs on top of agents. |
| 16:09 | <annevk> | URSOBC was always meant to be what similar-origin window agent actually is |
| 16:09 | <Domenic> | Browsing contexts have active documents which have origins. Having to do bc.activeDoc.origin instead of realm.{activeDoc|singleGlobal}.origin is not any fundamentally worse |
| 16:10 | <Domenic> | I don't really have any context for that historical claim so I'm not sure how to engage with it. |
| 16:10 | <annevk> | I mean to say that this was always a bit of a hack, an approximation |
| 16:12 | <annevk> | Implementations always had collections of documents instead (e.g., doc group in Gecko), and browsing contexts were managed separately (e.g., tab group in Gecko) |
| 16:13 | <annevk> | This might be a bit different in user agents that don't have multiple documents per browsing context though (e.g., Chrome does a lot with just _frame) |
| 16:16 | <Domenic> | Yeah, thus my latest (just now) ask for an overview. |
| 16:18 | <annevk> | Domenic: so I tried to sketch it out in OP; a BC group holds a map for agent clusters, when you navigate around you pick from that map and construct/deconstruct agents and realms in it |
| 16:18 | <annevk> | Domenic: and it also holds a set of browsing context trees that belong to the group |
| 16:20 | <Domenic> | annevk: what is the key in the map? |
| 16:20 | <annevk> | Domenic: the latter is mostly needed for targeting a browsing context via a name and to know which map to use |
| 16:20 | <annevk> | Domenic: for agent cluster it's site, but with the Spectre headers it could be ("Spectre, origin) |
| 16:20 | <annevk> | sorry, "Spectre" (as a bit) |
| 16:20 | <Domenic> | Do we have a definition for "site"? I thought we just had a yes/no predicate |
| 16:21 | <annevk> | Domenic: scheme + domain's registrable domain (https://url.spec.whatwg.org/#host-registrable-domain) |
| 16:21 | <Domenic> | Got it |
| 16:22 | <Domenic> | OK so that gives you an agent cluster... let's se... |
| 16:22 | <annevk> | Domenic: we could have a separate map for shared/service workers I think, those could always be origin-bound agent clusters |
| 16:22 | <annevk> | Domenic: as they don't have d.domain |
| 16:23 | <Domenic> | Are the values of the maps agents or agent clusters? |
| 16:23 | <Domenic> | Remember e.g. dedicated worker agents are inside the same agent cluster as their parent window |
| 16:23 | <annevk> | Domenic: need to be agent clusters I think for that reason |
| 16:23 | <Domenic> | Oh you said "shared/service" |
| 16:24 | <annevk> | We'd need a bunch of convenience members around this to manage it all easily |
| 16:24 | <Domenic> | How do you know when to create a new agent, in the window case? |
| 16:24 | <annevk> | And have something like a similar-origin window agent cluster perhaps |
| 16:24 | <Domenic> | I guess top-level versus not |
| 16:25 | <annevk> | Domenic: if the map returns nothing for your cluster, you need to create a cluster, if there's a cluster, there's an agent you can use most likely (unless you're the first, but then it would be created as part of creating a similar-origin window agent cluster I think) |
| 16:25 | <Domenic> | " if there's a cluster, there's an agent you can use most likely" seems wrong for new top-level windows? |
| 16:26 | <annevk> | Domenic: a new top-level is a new browsing context group, which means the map is empty |
| 16:26 | <Domenic> | Oh there's a whole new level of hierarchy, I forgot, I thought the map was top-level... |
| 16:27 | <annevk> | Domenic: e.g., noopener/noreferrer means new bcg |
| 16:27 | <Domenic> | Is there a single top-level BC per BC group? |
| 16:27 | <annevk> | yes |
| 16:27 | <Domenic> | OK, that wasn't clear from the OP |
| 16:27 | <annevk> | and zero or more auxiliary |
| 16:27 | <annevk> | though the single top-level could go away |
| 16:28 | <annevk> | anyway, glad we arrived here today 😃 |
| 16:28 | <Domenic> | Yep, thanks for walking me through it... |
| 16:29 | <annevk> | I'll try to clarify the design a bit more tomorrow and work out the exact setup we need for this |
| 16:29 | <annevk> | I waited a bit with that to see if there were any immediate concerns |
| 16:30 | <annevk> | Yeah, sorry it went a little sour, it's sometimes hard to pinpoint how to unstuck a conversation |
| 16:31 | <Domenic> | I guess I am more worried about the BroadcastChannel thing now too |
| 16:31 | <Domenic> | I wonder if we can get any Chrome multiprocess folks to comment |
| 16:32 | <annevk> | Domenic: there's still some problems with MessageChannel reportedly not working for SAB btw, due to being able to post it across threads, but not claim it, effectively leaking the SAB forever |
| 16:32 | <Domenic> | I mean that's true for anything in a MessageChannel, right? |
| 16:32 | <annevk> | Domenic: at least in the sense that nobody wanted to implement that for MessageChannel, but nobody raised the concern on whatwg/html either |
| 16:34 | <annevk> | Domenic: so I agree, but https://bugzilla.mozilla.org/show_bug.cgi?id=1360190#c9 |
| 16:34 | <annevk> | Domenic: I've asked repeatedly for that to be raised in public, but no luck |
| 16:34 | <annevk> | "in public" -> whatwg/html |
| 16:35 | <Domenic> | :-/ |
| 16:35 | <annevk> | Domenic: so yeah, BroadcastChannel is the only messaging thing that goes outside a browsing context group, but storage et al do too... |
| 16:36 | <Domenic> | Storage is more static though |
| 16:36 | <Domenic> | Seems totally separable |
| 16:37 | <Domenic> | Doesn't impact process creation choices |
| 16:37 | <annevk> | But cross-BCG BroadcastChannel would simply not support SAB which seems fine |
| 16:38 | <annevk> | And even intra-BCG it wouldn't always work due to different clusters existing |
| 16:38 | <annevk> | (It's actually an interesting question where shared/service workers get their agent clusters. They should probably not use a BCG, but some kind of global map.) |
| 16:39 | <annevk> | (Which has some implications for side channels as folks discovered, e.g., seeing how many shared workers can still be allocated.) |
| 22:19 | <Domenic> | annevk: were you planning to check out https://github.com/whatwg/html/pull/4115 ? Seems like the kind of work we should encourage :) |