Raw conversation of https://github.com/w3c/webdriver/issues/1503

gistfile1.txt

AutomatedTester> David Burns jgraham: morning!
9:05 AM I was reading https://github.com/w3c/webdriver/issues/1503 which makes perfect sense
9:05 AM I have some questions
9:07 AM What should happen if there multiple "realms" and people have requested different things from each realm at different times. Simplistic example: If I set up logging in each realm, will data be coming back from those realms simultaneously?
9:08 AM Not for the spec: how would people move between realms and know what realms are available to them?
9:08 AM → simonstewart joined ([email protected])
9:26 AM 
<AutomatedTester> David Burns What is the default realm? What defaults are we setting in the on the realms?
10:05 AM 
<jgraham> AutomatedTester: Yeah, good questions. My working assumption is that we will support targetting multiple realms, and getting events from multiple realms simultaneously. Each command/event will come with a realm id
10:06 AM I assume there won't be a default
10:06 AM There is an open question around the granularity of opting into events (per realm, per browsing context, etc.)
10:07 AM 
<simonstewart> "Per type of event"?
10:07 AM 
<jgraham> Right, but maybe in groups like CDP has domains that you opt into
10:08 AM 
<simonstewart> Yeah. That's what I'm thinking.
10:08 AM 
<jgraham> There is a tension between automation and devtools use cases here. In devtools you are usually enabling the events for a specific "target" which is one top level brosing context or similar
10:08 AM 
<simonstewart> Though things like the `Network` domain generate a ton of events, and it might be nice to be able to say "just send me `Network.requestCompleted`"
10:09 AM 
<jgraham> For automation it makes more sense to say that you just want everything. But maybe there are also use cases where you care about say perf events from a specific browsing context but don't want all the traffic of getting them from everywhere
10:09 AM Yeah
10:09 AM 
<simonstewart> Indeed.
10:10 AM The automation use-case is also more likely to have a proper network hop in, and not just be on localhost
10:10 AM 
<AutomatedTester> David Burns my concern is that in automation, especially in things like BrowserStack/Sauce, that getting everything may overwhelm the machines running the tests
10:10 AM 
<simonstewart> (though things like debugging Android or iOS browsers will have a network hop in, I guess)
10:10 AM 
<AutomatedTester> David Burns if people opt for everything
10:10 AM 
<jgraham> There was some chat about this in the previous "meeting"
10:11 AM I agree that we should care more about network latency than a devtools protocol does
10:12 AM This also came up in regard to value serialization at TPAC when the Chrome folks were complaining about needing N+1 roundtrips to serialize N array elements
10:12 AM 
<AutomatedTester> David Burns exactly
10:13 AM and that's internal to chromedriver roundtrips
10:13 AM 
<jgraham> I think people floated the idea for some kind of event filtering mechanism so you could pass a list of realms or browsing contexts or whatever for which you want certain events
10:13 AM Can imagine extending that to specific event names too
10:14 AM 
<simonstewart> IIRC, we discussed passing the events we wanted to the domain's `enable()` method, and assumed that the empty list was "give me everything"
10:14 AM 
<jgraham> Yeah, something like that makes sense
10:14 AM 
<simonstewart> I may not be recalling correctly :)
10:14 AM For local end bindings it's pretty clear: if you add a listener, then you want the event
10:15 AM 
<AutomatedTester> David Burns so... NOT for the spec but may guide the spec. How do people clients see what targets/realms are available?
10:15 AM 
<jgraham> (and re: value serialization, I put a proposal in the issue tracker which has recursive value types so you avoid the N+1 value)
10:15 AM s/value/problem/
10:15 AM AutomatedTester: That is for the spec
10:16 AM 
<AutomatedTester> David Burns I only say not for the spec as it's client specific
10:16 AM and historically we didnt want to influence the clients
10:16 AM 
<jgraham> AutomatedTester: The way it works in CDP is that when you enable runtime you get a list of contexts, and then you get events for new contexts, or something
10:16 AM Right but the protocol has to provide the necessary informaton somehow
10:16 AM The events make sense, but I think it also makes sense to have the ability to get a snapshot list
10:18 AM 
<simonstewart> Doesn't the `Target` domain have a `get targets` for a given session id?
10:18 AM https://chromedevtools.github.io/devtools-protocol/tot/Target/#method-getTargets
10:19 AM 
<jgraham> YEah, but those aren't execution contexts / realms are they? They're more like processes
10:19 AM 
<AutomatedTester> David Burns yea, we need to have a way to get updated targets list
10:19 AM 
<simonstewart> jgraham: gotcha
10:19 AM But the point that the relevant domain can expose a mechanism for introspecting that domain seems to make sense
10:21 AM 
<jgraham> Yeah, sketching out how you find out about what realms/browsing contexts exist and how you enable domains seems like the next step
10:22 AM I feel like that is the minimum amount of required infrastructure before you build out actual features like executing a script, or logging, or whatever