dbus-cplusplus-devel

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

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

Hello,

I've got 2 questions and one announcement.

First the announcement: I've finally started writing the libhalmm rewrite,
as a reimplementation of libhal,
instead of being a wrapper around the C libhal and libhal-storage.

Since the basic work is straightforward I expect that I can make an
announcement of the source code
within 1-2 weeks; I'll post again then with the checkout URL, etc.

Two questions:

1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
wanted to ask)

2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
in the public dbus-c++ headers"?
I thought we could get rid of some (IMO) stupid things in the DBus C API,
e.g. introduce an enum for the
message type. However, to take the values from the C API, the C header
dbus-protocol.h would need to
be included? How is the stance on this policy by now?


Cheers
Milosz

-- 
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

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

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

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 :)

Thanks
Milosz

On Sat, Jan 17, 2009 at 3:02 AM, Milosz Derezynski
<int...@gm...>wrote:

> Hello,
>
> I've got 2 questions and one announcement.
>
> First the announcement: I've finally started writing the libhalmm rewrite,
> as a reimplementation of libhal,
> instead of being a wrapper around the C libhal and libhal-storage.
>
> Since the basic work is straightforward I expect that I can make an
> announcement of the source code
> within 1-2 weeks; I'll post again then with the checkout URL, etc.
>
> Two questions:
>
> 1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
> wanted to ask)
>
> 2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
> in the public dbus-c++ headers"?
> I thought we could get rid of some (IMO) stupid things in the DBus C API,
> e.g. introduce an enum for the
> message type. However, to take the values from the C API, the C header
> dbus-protocol.h would need to
> be included? How is the stance on this policy by now?
>
>
> Cheers
> Milosz
>
> --
> Please note that according to the German law on data retention,
> information on every electronic information exchange with me is
> retained for a period of six months.
> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
> jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
>



-- 
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

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

[P. D. <sh...@gm...>]

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 :)
>

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.
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.

Paolo

> Thanks
> Milosz
>
> On Sat, Jan 17, 2009 at 3:02 AM, Milosz Derezynski <int...@gm...>
> wrote:
>>
>> Hello,
>>
>> I've got 2 questions and one announcement.
>>
>> First the announcement: I've finally started writing the libhalmm rewrite,
>> as a reimplementation of libhal,
>> instead of being a wrapper around the C libhal and libhal-storage.
>>
>> Since the basic work is straightforward I expect that I can make an
>> announcement of the source code
>> within 1-2 weeks; I'll post again then with the checkout URL, etc.
>>
>> Two questions:
>>
>> 1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
>> wanted to ask)
>>
>> 2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
>> in the public dbus-c++ headers"?
>> I thought we could get rid of some (IMO) stupid things in the DBus C API,
>> e.g. introduce an enum for the
>> message type. However, to take the values from the C API, the C header
>> dbus-protocol.h would need to
>> be included? How is the stance on this policy by now?
>>
>>
>> Cheers
>> Milosz
>>
>> --
>> Please note that according to the German law on data retention,
>> information on every electronic information exchange with me is
>> retained for a period of six months.
>> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
>> jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
>
>
>
> --
> Please note that according to the German law on data retention,
> information on every electronic information exchange with me is
> retained for a period of six months.
> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
> jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>
>

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.