[systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages

[Stanislav Angelovič]

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 (
https://lists.freedesktop.org/archives/systemd-devel/2016-November/037929.html).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190512/4d9c9896/attachment.html>