[PATCH] more dbus control interface functionality

[Jouni Malinen]

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

Thanks, appreciated.

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

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

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