GBus discussion
Havoc Pennington
hp at redhat.com
Sat Aug 18 05:50:21 PDT 2007
Hi,
On 8/17/07, Fan Wu <wufan9418 at gmail.com> wrote:
> There might be applications interested in the how/why a name is not
> owned, if JUST for logging purpose. Unless DBUS caches the error
> conditions and provides an API dbus_get_last_dbus_error() to retrieve
> the error message. My point is, we provide the error message and
> return code, users can use them to their desire. They can choose to
> leverage the application data as suggested in your post, or use the
> return code, or both. All the return code and error message are
> already exposed in libdbus, and I for one would appreciate the
> availability of the information.
>
Maybe we can come up with some way to make the "current" DBusMessage
available to apps inside the handler, without breaking the
abstraction? The simple way of course is to have a DBusMessage arg to
the handler function, which may be the only sane way.
There won't always be a predictable message - think about calling all
the not_owned handlers when the connection disconnects, I mean, in
that case there will be a Disconnected message, but not a reply to the
request name or a NameLost. Maybe the API could provide "the message
causing the not-owned, but it is unspecified what kind of message it
will be"
Purely for logging purposes an app could always install a message
filter on the DBusConnection and print messages then return
NOT_YET_HANDLED.
Havoc
More information about the dbus
mailing list