- commit
- ba30780c993fe3224182238438101fb58c3b739f
- parent
- 647052fe98a33e126299b9c262cc48c24ede404d
- Author
- Tobias Bengfort <tobias.bengfort@posteo.de>
- Date
- 2026-02-16 09:13
README: add motivation
Diffstat
| M | README.md | 55 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 files changed, 55 insertions, 0 deletions
diff --git a/README.md b/README.md
@@ -72,6 +72,61 @@ async def amain(): 72 72 asyncio.run(amain()) 73 73 ``` 74 74 -1 75 ## Motivation -1 76 -1 77 This library was born from my frustration with dbus. I wanted to see if that -1 78 frustration was caused by bad library design or if it was inherent in the -1 79 protocol. -1 80 -1 81 ### Verbosity -1 82 -1 83 `org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop -1 84 org.freedesktop.portal.Settings ReadOne` is extremely verbose and redundant. An -1 85 equivalent HTTP endpoint would probably be called -1 86 `desktop.portal.freedesktop.org/settings/ReadOne`, which is so much better. -1 87 Sure, namespacing has its benefits. But this is just excessive. -1 88 -1 89 This is mostly an issue in the protocol. Applications could make this slightly -1 90 better by choosing `/` as the path for their primary object, but even that is -1 91 discouraged by the spec. -1 92 -1 93 `GDBusProxy` is also more of a workaround than a solution. The fact that it -1 94 is a proxy for interfaces rather than objects is an indicator that those two -1 95 concepts are at least partially redundant. -1 96 -1 97 My workaround here is to use the first matching path / interface that can be -1 98 found. This has a performance penalty and is brittle (e.g. if conflicting -1 99 interfaces are added later on), so this is not a real solution either. -1 100 -1 101 IMHO the real solution would be to enforce `/` as the primary object path and -1 102 to do away with interfaces. In practice there are not so many interfaces on the -1 103 same object that collisions are a real issue. -1 104 -1 105 ### Signatures -1 106 -1 107 In order to encode a dbus message, you need to know its type signature. In the -1 108 glib implementation, the caller must provide that signature. I added the option -1 109 to omit the signature, in which case it is received via introspection. Deriving -1 110 the signature from python types is not easily possible because it is unclear -1 111 how to differentiate `INT32` from `UINT64` or `STRING` from `OBJECT_PATH`. -1 112 -1 113 A special case of this are variant types, where the type is only known at -1 114 runtime. I chose to represent them as simple `(signature, value)` tuples. -1 115 -1 116 ### Custom wire format -1 117 -1 118 The most complex part of this library is the implementation of the custom wire -1 119 format. This would be much easier if dbus would reuse an existing format like -1 120 MessagePack, CBOR, or even JSON. (Each of these of course come with their own -1 121 pros and cons.) -1 122 -1 123 ### Layers -1 124 -1 125 That said, I really like how the different layers of this protocol are stacked -1 126 on top of each other. Once you have the wire format, you can build messages on -1 127 top of that. Then you can build method calls and signals on top of messages. -1 128 Finally, you can build introspection and property access on top of method calls. -1 129 75 130 ## Links 76 131 77 132 - [dbus-next](https://github.com/altdesktop/python-dbus-next) and its forks