Make sure future protocol accomodates all applications/use cases
Creating an issue here, since the proposal for a new protocol has been added here in commit a89a6476. (Please let me know if it's better to mention elsewhere.
The proposal for a new protocol mentions (emphasis added):
The push approach does have risks. In particular, because it requires all details of an accessibility tree to be pushed up front, there is a risk that, particularly for large, complex trees, such as long text documents and large lists or tables, performance may be degraded compared to a pull-based approach where clients send queries on demand via IPC. However, for lists or tables, in both native and web applications, it's common to implement a virtualized view, where view-level data structures are created lazily for only a portion of the full dataset. We believe that it's similarly feasible to virtualize large text documents, though this needs to be done carefully to avoid degrading the functionality that AT users have come to expect. Some legacy providers may have been implemented with the assumption that the accessibility tree is queried lazily, rather than being traversed in its entirety up-front. If we find that this is a problem in practice, it may be necessary for such providers to stay on AT-SPI rather than the new architecture. It will likely not be possible to completely discontinue AT-SPI support anyway.
In my opinion, any new protocol that gets introduced should ensure that it's suitable for all use cases/applications. Having to maintain both, AT-SPI2 and any successor, in parallel indefinitely and having to support both of them in AT sounds like a maintenance nightmare to me.
Therefore, please consider making sure that the new protocol can cover all uses cases properly.
Large text documents are mentioned as one potentially problematic use case, so LibreOffice would be one of the affected candidates for which always pushing the whole tree may not be feasible for performance reasons.
Please make sure that such uses are covered in the new protocol. If applications need to rework the way they handle a11y, please provide a clear guideline on what the expected way to do this should be.
(Side note: In general, I think there's also some value in the protocol not being conceptually "totally different" from anything else that exists, e.g. to simplify the migration from AT-SPI2 and allow implementing applications/toolkits to support other platforms (like IAccessible2/UIA on Windows, NSAccessibility on macOS) in parallel. Of course, that's a matter of assessing pros and cons in the end.)