-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement GUI protocol 1.4 #105
Conversation
dbedc23
to
603ac11
Compare
Build is broken because this has a hard dependency on QubesOS/qubes-gui-common#16. |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.1&build=2022071409-4.1&flavor=pull-requests New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.1&build=2022062106-4.1&flavor=update
Failed tests31 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/42506#dependencies 6 fixed
Unstable tests
|
It can at least theoretically fail.
It may fail due to out of memory or other reasons.
Instead of using protocol version, I suggest we use feature detection and never change the semantic of message types. For example, we rename current message Then we can have If we change the semantic of API, the endpoint name should change. Feature detection is better to understand than mysterious code like only using version:
Feature detection
|
@locriacyber The problem with this is that it requires support from both daemon and agent, and right now neither have such support. Therefore, there needs to be some way to announce support for this. Also, having to deal with all possible feature bits is a testing nightmare. Just having to deal with all the different version combinations will be hard enough. |
This implements GUI protocol v1.4, which includes bidirectional protocol negotiation. This means that not only does the agent tell the daemon what protocol version it supports, the daemon also tells the agent what protocol version it decided to actually use. This may be less than the version supported by the agent. As a result, a GUI daemon including this patch may be used with any version of the GUI agent supporting protocol major version 1, even ones that support higher minor versions than the daemon does.
This avoids having to bump build dependency versions and allows CI to run.
@DemiMarie This is more like 2.0 rather than 1.4? Since newer clients will not work with older server. I'll try to rebase my patch for the server on this. |
Yes, but older clients will work with newer server. And it was always required that daemon proto version >= agent proto version. |
This allows bidirectional protocol negotiation, which means that the
agent can be newer than the daemon.
The daemon must be upgraded to support protocol 1.4 first. Afterwards,
agents and daemons can be independently upgraded.