GBus discussion

[Fan Wu]

Sorry I didn't make myself clear when referring to "error message".
What I meant was DBusError which I think include both the error
DBusMessages and the errors set by the libdbus (reply timeout, or bad
DBusMessage etc), and pass the DBusError to the callbacks.

Fan

On 8/18/07, Havoc Pennington <hp at redhat.com> wrote:
> 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
>