Issues with new D-Bus API

[Witold Sowa]

Jouni Malinen pisze:
> On Mon, Jan 04, 2010 at 02:02:34AM -0800, Marcel Holtmann wrote:
> 
>> so besides the BSS change notification (which doesn't apply anymore), I
>> have send all patches to the mailing list. Just use git am to apply them
>> and to keep the authorship. For reference they are in this order:
>>
>> [PATCH] dbus: Use simple strings for debug level
>> [PATCH] dbus: Replace StateChanged with PropertiesChanged signal
>> [PATCH] dbus: fix BSS WPS/WPA/RSN IE property getters
>> [PATCH] dbus: Change BSS property MaxRate to Rates
>> [PATCH] dbus: aggregate PropertiesChanged signals
> 
> Thanks! I applied all but the third one. As far as the IE properties are
> concerned, this changed would seem to make it impossible to distinguish
> a zero-length IE from completely missing IE. In these particular three
> IEs, that may not be that much of an issue, but in general, this is not
> a good direction to go. In addition, the WPS IE case is already broken
> since there may be multiple of those in a frame.
> 
We include the type and length bytes in an IE property so in case of a
zero-lenght IE we will get a 2-byte array with the second byte equal to
zero.
In case of WPS IE we would get the concatenated IEs with
wpa_bss_get_vendor_ie_multi().

> I would prefer to make all IEs available in a single property (i.e.,
> just the data as-is from the BSS entry). If we need some additional
> information, like the TLVs from reassembled WPS IE(s), that could
> certainly be provided. Similarly, I would like to understand what the
> clients are doing with WPA/RSN IE information? If they just need to know
> whether the IE was there, it would be better to use boolean for that. If
> they need to process the data somehow, they could almost as easily fetch
> it from the all-IEs array. If they want to avoid parsing, we could
> provide some parsed information (e.g., cipher suite).
> 
NetworkManager parses WPA and RSN IEs. It would be nice to have it done
in supplicant.
NetworkManager doesn't make any use of WPS IE yet, but probably will
sooner of later. If we would parse WPS IE too then we're great.
We can expose whole IE byte array in case if parsed information wouldn't
be enough for some client.

> As far as missing a property from some objects is concerned, I'm not
> sure I fully understand why that would be an issue. Is there a D-Bus
> specification saying that every property listed in the introspection XML
> data must be available for every object? Is introspection done
> separately for each object or for the interface defining those objects
> in general (and then same results shared for all objects implementing
> that interface)?
> 
Well, DBus specification doesn't say anything about consistency of
introspection data with real object properties/methods/signals, but IMO
it could be very confusing for client if properties shown in
introspection wouldn't be implemented by the object. Clients might as
well guess if property is there or it isn't.

Introspection is done separately for object so in theory we would have
different introspection data for two objects implementing the same
interface, but:
1) It seams much cleaner to have well defined, stable interface and
implement all its methods an properties. It's easier for client and it's
easier for us in wpa_supllicant impelenetation. What we could
alternatively do is to implement some interfaces optionally (e.g. BSS
interface is implemented by all BSS objects, but WPS interface is
implemented only by those which support WPS) but it doesn't really
convince me too.
2) Adding/removing methods, properties or whole interfaces while object
is already registered may require quite heavy code modifications.

Regards,
Witek.