Meeting minutes
Draft of Standard API, Protocol section
zcorpan: presenting from this link: https://
zcorpan: PR here (https://
James Scholes: so if i understand correctly, this document outlines how the connection and what is sent / received from either end... but it doesn't specify exactly how the AT would need to connect?
zcorpan: that's correct. we may want ourselves to create a separate document that outlines more detail around how the AT connects
James Scholes: i do think we should figure out when, how, and who are going to work on a higher level abstraction / library around the protocol (e.g. similar in scope to playwright or selenium)
s3ththompson: i think there are 3 different layers we're talking about here: the Standard (which defines protocol and expectations for the behaviors on the other end of the protocol, the libraries built on top (e.g. playwright), and perhaps the At-specific architectural considerations which aren't part of the standard but may need to be documented separately
Matt King: I'm hoping that simon can help us understand what things should be where in the spec (and what things don't need to be spec'd, e.g. what could be a design document or a Note) and james can help on the implementation side by figuring out what stuff we have an opinion on and what stuff we don't
Matt King: what about the ability to restart the screenreader, etc.? don't we need to have a set of expectations regarding what the server would be able to do with the screen reader?
James Scholes: so if there's a command like "restart server" it would be up to the AT-specific server to figure out the best way to negotiate that architecturally with the AT itself.
s3ththompson: I think that's right, at least to start... that way we reduce the amount that we need to get consensus on
Matt King: let's make sure we explicitly send this to the vendors for feedback. simon if you could create an issue and cc them directly
Matt King: i also want to make sure that whereever something is not in scope for the spec and left up to vendor implementation, that James takes point designing that for NVDA
s3ththompson: i think it sounds like already we know we won't be specifying more about the server architecture for the protocol remote end, so maybe that's something that you could already start working on
Michael Fairchild: it sounds good to me so far, but please cc me after you make edits and when you get ready to send for review
<zcorpan> RRSAgent: make minutes