[PATCH] dbus-1: Adds helpers to create/parse a request name message/reply.

[Simon McVittie]

On 10/01/14 15:07, Mathias Berchtold wrote:
> The general idea is to separate the message building/parsing from the
> transport mechanism. The proposed patch gives a client of libdbus more
> freedom in this regard without the need to duplicate the code.

Thanks, but I'm inclined to say "no" to this. If you need to do async
name-requests, I don't think duplicating this logic is onerous. The
structure of a RequestName message is given by the D-Bus Specification,
so it's not going to change; and you'd need remarkably similar logic for
any other asynchronous method call anyway.

If you have some sort of generic framework for asynchronous calls (like
the ones in GDBus, QtDBus, dbus-python or the deprecated dbus-glib), it
would be far easier for you to use that for RequestName too.
dbus_bus_request_name is purely "convenience API": it's easy to
reimplement in terms of libdbus public API.

If possible I strongly recommend using an API that is actually
high-level, like the GDBus APIs in GLib: you might have noticed that
libdbus is far from being a high-level library. g_bus_own_name() or
g_bus_own_name_on_connection() is a much better API for this sort of thing.

Regards,
    S