Re: [systemd-devel] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On 05/12/13 12:13, Lukasz Skalski wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This is rarely-needed functionality, but sometimes necessary. If anyone is going to replicate the client-facing functionality of the dbus-daemon using libsystemd-bus, you'll need this for NameAcquired and NameLost; and I've seen other real-world APIs where unicast signals were also desirable. Depending where you want to be on a scale from maximally flexible to promote the common case, and make the rare case slightly tedious you could either add the parameter all the time as in Lucasz' patch, or go for something more like this to encourage those in doubt to use the more conventional broadcast signals: int sd_bus_message_new_signal(sd_bus *bus, const char *path, const char *interface, const char *member, sd_bus_message **m); int sd_bus_message_new_unicast_signal(sd_bus *bus, const char *destination, /* must be non-NULL */ const char *path, const char *interface, const char *member, sd_bus_message **m); Regards, S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On Thu, 05.12.13 13:13, Lukasz Skalski (l.skal...@partner.samsung.com) wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This path makes libsystemd-bus API more consistent and similar to GDBUS API, for reference: Hmm, I thought about this for a while. And decided not do that since setting a destination is certainly the exception not the rule, and a very seldom exception. And we do cover this by allowing people to create the message first, then attach the destination to it, and then send it. In fact I recently went through the API and tried to get rid of all parameters that I could get rid of, that I felt weren't really necessary. I am pretty sure I don't want to reverse this... Sorry, but this really was a concious decision. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On Thu, 05.12.13 13:09, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 05/12/13 12:13, Lukasz Skalski wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This is rarely-needed functionality, but sometimes necessary. If anyone is going to replicate the client-facing functionality of the dbus-daemon using libsystemd-bus, you'll need this for NameAcquired and NameLost; and I've seen other real-world APIs where unicast signals were also desirable. Note that libsystemd-bus when used on top of kdbus actually gets rid of NameLost/NameAcquired. They are entirely redundant due to NameOwnerChanged, and people should just use that. libsystemd-bus when used against dbus-daemon will still get these though. And the compat proxy will fake them in too, so that dbus1 clients continue to work. BTW, I started documenting the differences between dbus1 and kdbus a bit here: http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/DIFFERENCES We also want to enforce gvariant native endian marshalling on kdbus, and I documented how we map things to the old structures then: http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/GVARIANT-SERIALIZATION I just put those docs together yesterday. Eventually I'll submit them for the dbus spec. This makes no attempt of establishing gvariant as an alternative marshalling on socket connections, it's only focussed on kdbus transports so far. We could allow it on sockets too though, but this requires explicit nego to stay compatible. Either way systemd-bus-proxyd will do the necessary remarshalling when connecting dbus1 clients to kdbus. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
