Re: [dbus-cplusplus-devel] Question about patches / Question about DBus C header inclusion policies

[Milosz D. <int...@gm...>]

Yes sorry I meant type().

What has led me to wanting to do this is this code from libhal:

static DBusHandlerResult
filter_func (DBusConnection * connection,
         DBusMessage * message, void *user_data)
{
    const char *object_path;
    DBusError error;
    LibHalContext *ctx = (LibHalContext *) user_data;

    if (ctx->is_shutdown)
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;

    dbus_error_init (&error);

    object_path = dbus_message_get_path (message);

...

}



A few things to observe:

get_path() is implemented on dbus_message_ directly. Is there a specific
reason this is only implemented on
SignalMessage in dbus-c++?

Furthermore, the object path is used further down this code, for some cases
of the message, for some cases not.

I'm not sure how to elaborate on that since you have


On Sat, Jan 17, 2009 at 4:39 AM, P. Durante <sh...@gm...> wrote:

> On Sat, Jan 17, 2009 at 3:03 AM, Milosz Derezynski
> <int...@gm...> wrote:
> > I just realized that DBus::Message::get_type() also returns just an int.
> For
> > this to make any sense, that is,
> > so API consumers can compare this to the known message types, they have
> to
> > include the dbus-protocol.h
> > anyway, or they (bad!) just hardcode the numbers.
> >
> > So either way it seems that header is needed. But aside from that, the
> > question about whether C headers
> > can generally be included or not still stands :)
> >
>

Since I'm not sure right now why you avoid my entire main message I won't
comment on that further,
it's just that no matter whether I currently understand everything (or maybe
you just don't understand
what I am doing), I would have expected a nicer welcome for someone who is
trying to help out,
unless you don't welcome people helping out in general, i.e. prefer to work
alone on it.


> What I'm wondering is where you're getting these messages from and why
> you have to manually cast them to the appropriate message type.


Well since you're wondering so much, I'm getting the message from a filter
handler
installed by using add_filter().

This is code from C libhal:

static DBusHandlerResult
filter_func (DBusConnection * connection, DBusMessage * message, void
*user_data)
{
    const char *object_path;
    DBusError error;
    LibHalContext *ctx = (LibHalContext *) user_data;

    if (ctx->is_shutdown)
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;

    dbus_error_init (&error);

    object_path = dbus_message_get_path (message)

...

}

The object path is used for some callbacks i.e. for some handlers for
specific signals from HAL, for example:

...

if (dbus_message_is_signal (message,
"org.freedesktop.Hal.Device","InterfaceLockAcquired")) {
        char *lock_name;
        char *lock_owner;
                int num_locks;
        if (dbus_message_get_args (message, &error,
                       DBUS_TYPE_STRING, &lock_name,
                       DBUS_TYPE_STRING, &lock_owner,
                       DBUS_TYPE_INT32, &num_locks,
                       DBUS_TYPE_INVALID)) {
            if (ctx->interface_lock_acquired != NULL) {
                ctx->interface_lock_acquired (ctx, object_path, lock_name,
lock_owner, num_locks);
            }
        } else {
            LIBHAL_FREE_DBUS_ERROR(&error);
        }
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}

...

Now I'm not sure how to ask this because there are a few angles possible
from which to approach it,
so I'll ask it from this one: Why is ::path() not implemented in Message,
but only in SignalMessage?

And if that is the right way to do it, and the message in the filter
function is in fact always a SignalMessage
(which it will not always be but let's assume it were), then the filter
function signature surely should be
bool (*func) (const SignalMessage&) no?

OK, but it's not, so I guess you can see my reasoning for wanting to cast
it, since all types of messages can
arrive at the filtering function.


> The way I see it Message::type() (there's no such thing as get_type())
> shouldn't be in the public API at all since the returned value is only
> used internally to route the message appropriately.
>

Yes i meant type(). Well, maybe so, but in the filtering function this
clearly doesn't work out.


>
> Paolo


Regards,
M.

It's OK to assume that I don't know everything, but assuming that I
understand
nothing is maybe not the right approach.