RRSAgent: silence

RRSAgent: silence

<jgraham> brrian: You know the meeting is now and not in 30 minutes?

<scribe> scribe: AutomatedTester

Follow-ups from previous meeting

bwalderman: In the previous meeting we said that we would start splitting out to multiple documents
... The issues on the github seems to capture the priorities of what needs to be worked on

<foolip> The list of issues: https://github.com/w3c/webdriver/labels/BiDi

bwalderman: Establishing a connection, this seems to not be controversial
... execute script and how this works
... Events coming back from the browser and how to filter those
... serialization format of JS Objects
... Figure out of the goals for things that we need to work on
... specifying a low level transport protocol
... Those seem to be the most important things that need addressing
... I was hoping to get consensus on the low level protocol by the end of this meeting

<foolip> The repo is https://github.com/jgraham/webdriver-bidi

jgraham: So I created an empty spec doc and have started speaking to foolip about organisation
... I am not sure if the tooling can handle this
... the general consensus for the W3C is that 1 spec per repo

<drousso> can someone let me into the meeting?

<drousso> i got DCd

<mathiasbynens> rendered version: https://jgraham.github.io/webdriver-bidi/

<drousso> thanks :)

foolip: I think its quite easy to have separate
... bikeshed files but there would be issues with how it does cross references
... I dont think we should preemptively split the docs

bwalderman: I think it makes sense to keep the output as 1 doc
... my understanding from splitting out the work was to have diff work streams not anything else

<jgraham> sgtm

cb: it would be good if we can have the definitions of API to be machine readable
... I would like to maintain an OpenAPI version of the spec at least

mathiasbynens: there is broad agreement for multiple streams to be merged to an upstream spec, like TC39

<foolip> Which issue?

bwalderman: having a machine readable version of the spec is great, I am not familiar with OpenAPI

cb: I need to investigate

jgraham: the machine readable version should be normative items to simplify things

<Hexcles> Found https://open-rpc.org/beginners for describing JSON-RPC

<jgraham> Oh I was also going to say that TC39-style in-progress stuff that gets merged in sounds like a good idea

foolip: being able to extract this is great, but we can go patch BS if we need to, Tab will likely handle it

SPec organisation

jgraham: I have created an empty spec, and get w3c/webdriver-bidi is where it should likely live

<mathiasbynens> sgtm

<foolip> sgtm2

<bwalderman> sgtm

<scribe> ACTION: David Burns to get w3c/webdriver-bidi setup with MikeSmith

Minimal feature to prove out in spec prose / impl prototype

foolip: I was thinking in these discussions to have something very concrete item of the spec
... what good candidates are there? User prompt notifications and logging
... are there more simple things in this category?

jgraham: do the simplest feature, which I feel like logging
... it needs the transport and then we can see what data is being sent back and forth

<foolip> jgraham: note that when you do console.log(document), that would log a handle, not a string, so it does pull in some other issues

jgraham: the other direction we can go for simplest protocol and that means something like script execution
... like pinning scripts, which are setup before [age is loaded

bwalderman: these two features seem like good places to start
... user prompts are interesting since its already handled in webdriver and we can see if there something we can improve from webdriver HTTP

<jgraham> foolip: Sure but it's a bit useless if you can't don't anything with that handle, and doing something with it requires a different set of APIs which executeScript would allow you to shim :)

<jgraham> *can't do

<foolip> jgraham: ack

AutomatedTester: how would this work if the prompt, blocks the event loop

jgraham: this already works in CDP so shouldnt be an issue

low-level transport protocol

https://github.com/w3c/webdriver/issues/1498

bwalderman: I would like to get consensus on this issue so that we can start writing this spec prose
... there is some discussion in the issue that is like JSONRPC but not exactly the same as we dont need all the same items
... client to browser commands are [description of shape of packet]
... browser to client [description of shape of packet]
... errors would be better if we can follow what is in the webdriver spec?
... my proposal is that we go with what has been described in the issue

foolip: it sounds good to me. I would like to check how we plan to put this into spec language.

<shengfa_> Sorry, regarding the previous item, one simple feature I can think of is for minimizing window, and not having to poll the window state to know it's minimized.

jgraham: We would describe we spec what webdriver calls remote end and what behaviour for any input and not impose requirements on the client
... whatever the client does we make sure our client has a response
... going back to the topic, that is fine and it is not controversial
... I wonder if we want to adopt a schema like language so how it is described in the spec
... we might have better way to describe things

bwalderman: before we discussed this early, I didnt I have a thought on how it would like.
... it is an interesting idea having an enum of error codes
... I am not sure what type of language we want to spec this in

zcorpan: how did we come to websocket vs http2 or http3?

jgraham: the honest answer is because that is what CDP uses for items and other existing clients already use
... I am not sure what the library support is for http2 push

brrian: I think that http2/http3 is premature, as its not widely supported

q>

bwalderman: library support is widely supported. the http2 push is not really designed back and forth comms and doesnt really align with what we want to do with the protocol

Hexcles: it wouldnt be http3, it would be webtransport which is based off QUIC and again the library support is poor

Supporting both HTTP and WebSocket

zcorpan: when we reviewed the proposal for this, I wanted to know what the rational is for this?

bwalderman: the rational is to give existing webdriver users an upgrade path over time
... it would be nice to create something new but dont think it would be good for the community

jgraham: the same as bwalderman here
... for implementors it means that we can slow build up features and allow people to slowly move over

AutomatedTester: we need to be aware of scalibility issues with cloud providers over time

zcorpan: I understand the concern, the but they are using client libraries which should do it for them
... so where do we want to end up in the end?

bwalderman: people are not upgrading their selenium versions regular so we are likely to support this for many years
... libraries wouldnt be able to support features for a while
... would people have to support http over websockets

jgraham: I think this is premature to worry about this is because its used extensively.
... the only thing we need to care about is using newSession to get the initial bidi connection
... There are mechanisms that people could do to support this
... no one has given a compelling use case for getting rid of the http stuff

<foolip> AutomatedTester: thanks for chairing and taking notes!

<cb> +1

<foolip> AutomatedTester: there were actually two more items at the end, I think I'll delete from from the wiki though

RRSAgent: make notes

<jgraham> RRSAgent: make minutes

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: AutomatedTester JohnJansen boazsender Hexcles shengfa_ diemol
Found Scribe: AutomatedTester
Inferring ScribeNick: AutomatedTester
Agenda: https://www.w3.org/wiki/WebDriver/2019-05-BiDi

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: burns david

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)