<div dir="ltr"><div dir="ltr">Hi (Lennart :) Quick question: Would it be possible to extend sd-bus to also allow creating messages without requiring a bus? Let me explain: Currently, if we want to create any message in sd-bus, we need a valid bus pointer. That might make perfect sense for messages that come from or will eventually go to bus. But sd-bus also supports plain messages. Do we also need that hard msg->bus dependency for plain messages which we use only as a local, temporary storage of serialized data? Some years ago we had a little discussion about a few tweaks in sd-bus API to allow modelling the concept of Variant type in higher-level sd-bus bindings (<a href="https://lists.freedesktop.org/archives/systemd-devel/2016-November/037929.html">https://lists.freedesktop.org/archives/systemd-devel/2016-November/037929.html</a>). A Variant is essentially implemented as a class around plain sd-bus message which is only used a storage of the underlying type. To create a Variant instance, we simply call `sd_bus_message_new` factory with type _SD_BUS_MESSAGE_TYPE_INVALID. Nice and simple. But that factory requires real bus ptr. This leads to a more complicated, less efficient and not-that-nice solution that must take hold of some bus (if there is none it must create one), must cache the bus (so that it's not created and destroyed at every creation/deletion of Variant instance). Yes, we have `sd_bus_default_system`, but even with that there is some effort that has some pitfalls (e.g. we can't `std::move` a Variant to a different thread, because it might potentially outlive the current one). All that nomenclature is needed just to get a plain message to read/write data from. It looks like the bus is not really needed when the message is used as a local storage only, i.e. when only these API functions are used: * creating plain, empty message (`sd_bus_message_new`) * writing/reading to/from the message (`sd_bus_message_append*`, `sd_bus_message_read*`, ...) * sealing the message (`sd_bus_message_seal` * copying to/from the message (`sd_bus_message_copy`) * rewinding the message (`sd_bus_message_rewind`) * peeking message type (`sd_bus_message_peek_type`) * reffing/unreffing the message (sd_bus_message_ref/unref`) Even today, vast majority of these functions doesn't seem to need the bus. The exception are `sd_bus_message_seal` and `sd_bus_message_new` itself. We'd need to either modify `sd_bus_message_new` to allow taking in NULL bus ptr, or creating a new function for creating such plain local messages. We'd need to modify `sd_bus_message_seal` to simply consider the fact that m->bus can be NULL. And we'd probably need to add asserts for m->bus to functions which truly require real bus ptr presence. (We might even provide the option to link the message to a real bus later, and introduce new `sd_bus_message_set_bus` function, but I'm not sure whether that is good.) To summarize: sd-bus already offers API for creating plain message. To make it fully true, let's just not require the bus there. The proposed change would IMHO make sd-bus message more flexible, and would make it easier, more intuitive and more robust to work with and model Variants around such free-standing, bus-independent sd-bus messages in higher-level languages. What do you think? Thank you, and kind regards, Stanislav. </div></div>