-
Notifications
You must be signed in to change notification settings - Fork 17
docs: clarify Service.interface(), VarlinkError, RequestHandler, and server classes #87
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -28,16 +28,29 @@ class Service: | |||||||||||||||||
| >>> ) | ||||||||||||||||||
| For the class implementing the methods of a specific varlink interface | ||||||||||||||||||
| a decorator is used: | ||||||||||||||||||
| the ``@service.interface()`` decorator is used. The argument is a varlink | ||||||||||||||||||
| interface name, **not** a Python class. The decorator loads the file | ||||||||||||||||||
| ``{name}.varlink`` from the ``interface_dir`` given to the Service constructor. | ||||||||||||||||||
| For example, ``@service.interface('com.redhat.system.accounts')`` loads | ||||||||||||||||||
| ``com.redhat.system.accounts.varlink`` from ``interface_dir``: | ||||||||||||||||||
| >>> @service.interface('com.redhat.system.accounts') | ||||||||||||||||||
| >>> class Accounts: | ||||||||||||||||||
| >>> pass | ||||||||||||||||||
| >>> def GetAccounts(self): | ||||||||||||||||||
| >>> return {"accounts": []} | ||||||||||||||||||
| The varlink file corresponding to this interface is loaded from the 'interface_dir' | ||||||||||||||||||
| specified in the constructor of the Service. It has to end in '.varlink'. | ||||||||||||||||||
| The methods defined on the decorated class directly implement the varlink | ||||||||||||||||||
| interface methods. Each method receives the varlink call parameters as | ||||||||||||||||||
| keyword arguments and must return a dict matching the method's return type. | ||||||||||||||||||
|
||||||||||||||||||
| keyword arguments and must return a dict matching the method's return type. | |
| positional arguments (in the order of the method's input fields) and must | |
| return a dict matching the method's return type. Additional information may | |
| be passed via special keyword-only parameters (such as ``_raw``, ``_message``, | |
| or ``_more``), if supported by the Service implementation. |
Copilot
AI
Feb 12, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The example mixes unqualified Service(...) with varlink.RequestHandler/varlink.ThreadingServer, but it never shows import varlink (or from varlink import Service). In a typical import varlink usage, Service won’t be in scope, so the snippet is not directly runnable as written. Consider either fully-qualifying the Service construction (varlink.Service(...)) or dropping the varlink. prefixes and keeping everything module-local.
| >>> class ServiceRequestHandler(varlink.RequestHandler): | |
| >>> service = service | |
| >>> | |
| >>> server = varlink.ThreadingServer("unix:@example", ServiceRequestHandler) | |
| >>> class ServiceRequestHandler(RequestHandler): | |
| >>> service = service | |
| >>> | |
| >>> server = ThreadingServer("unix:@example", ServiceRequestHandler) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The module docstring describes
varlink.Serveras a “single-connection base server”, butServer(likesocketserver.TCPServer) can accept multiple connections sequentially; it’s single-threaded / non-concurrent rather than single-connection. Rewording would avoid implying it only handles one connection total.