RRSAgent: silence
RRSAgent: silence
<jgraham> brrian: You know the meeting is now and not in 30 minutes?
<scribe> scribe: AutomatedTester
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
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
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
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
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.)[End of scribe.perl diagnostic output]