[PATCH] more dbus control interface functionality
jkmaline at cc.hut.fi
Thu Jun 22 23:04:52 EDT 2006
On Thu, Jun 22, 2006 at 07:56:13AM -0400, Dan Williams wrote:
> I can take a stab at cleaning them up, based on your comments. You've
> probably got better things to do :)
> Not a whole bunch, I think, so you're probably right here. The main
> missing item from the dict helper code is arrays of strings, but that's
> not so hard to add twice. We need to strike a balance here between the
> raw dbus API and the one presented by the helper code; can't make it too
> complex or we might just as well use the dbus API directly.
> So; I will re-style the dbus-dict-helper.* files for wpa_supplicant,
> including documentation comments.
OK, I think we can handle this for now and if there is more activity on
this area and multiple users, making it a separate library could be
> Yes, dbus messages can also be errors/exceptions. If I perform a method
> call on your dbus object, and an error occurs in your object while
> handling that method call, you can throw an error that I may handle.
> dbus errors are _not_ exceptions in the traditional C++/Python sense.
> They are simply DBusMessage objects with an "error" type, no different
> than a method call or a method return. Language bindings may do with
> them what they want; Python converts them to standard python exceptions
> (as you see in the example I provide), C++ & Java bindings may convert
> them to exceptions, but in plain C it is up to the caller to handle
OK. The word "exception" as in the sense of C++ exceptions was just
something I did not want to see anywhere near wpa_supplicant ;-).
> When you make a method call you do:
> reply = dbus_connection_send_with_reply_and_block (con, message,
> <timeout>, &error);
> Here, the &error is a local error variable if an error occurs before the
> message is sent. But the 'reply' argument may be the actual method
> return, or it can be an error.
This is perfectly fine with me.
> Quite; I'm going to need to add more than a few callbacks like this for
> the dbus stuff, and I'm sure the normal socket-based control interface
> would like to know about the same events.
> So for now I'll leave this as-is, but going forward lets identify all
> the place that need events and work out a solution for them.
OK. I'm fine with adding direct calls now and cleaning them up later
when more users show up.
Jouni Malinen PGP id EFC895FA
More information about the HostAP