Issues with new D-Bus API

[Jouni Malinen]

On Mon, Jan 04, 2010 at 06:42:25PM +0100, Witold Sowa wrote:

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

OK, I missed that.

> In case of WPS IE we would get the concatenated IEs with
> wpa_bss_get_vendor_ie_multi().

That would probably be better taken into account that we do not yet have
any known users of the new property and the concatenated information is
really what one would be after. The end result is not an IE, so this
should not be called WPSIE anymore, though.

> NetworkManager parses WPA and RSN IEs. It would be nice to have it done
> in supplicant.

Do we have a list (or can easily generate it) of information that
NetworkManager (or ConnMan, etc., for that matter) currently need from
these IEs?

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

I think that at least with WPS, we could start by removing the WPSIE
property and provide a new property with all IEs so that no information
is dropped. In addition, we could start adding parsed WPS information
based on the real need of the users of the D-Bus interface. Since this
is a new interface, I would do same with WPS/RSN IE, too, i.e., only add
information that is actually of known use (and provide all IEs for
unknown future uses now and more properties in the future, when needed).

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

What would the client use the introspection data for? Debuggers can
obviously use it to show everything that is available (and both d-feet
and qdbusviewer seem to be able to handle missing values), but real
applications using wpa_supplicant would unlikely be looking for some
properties that they know nothing about in the first place. In other
words, I would assume the introspection data is mainly there to allow
the client to figure out correct types, etc., automatically (ignoring
the debuggers part). If we define some of the properties to be
optionally included in the specification of the D-Bus API provided by
wpa_supplicant (and still include them in introspection data), I see no
harm in doing that.

The immediate question of WPAIE, RSNIE, and WPSIE can obviously be
removed by just removing all them and adding a single IE property which
will always be included (which is fine since there will always be IEs in
BSS entries). However, the same question will show up with the new
"more parsed" information, like, WPA/WPA2 cipher suite. How would that
be presented in the case that the BSS does not use WPA/WPA2 in the first
place? Not including the property for some BSS objects would sound
reasonable to me, but then again, I'm not that familiar with common
D-Bus usage.

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

I agree with the "well defined, stable interface" part, but I do not see
how not including some of the properties on some BSS objects would
conflict with that or how it would make this any more difficult for a
client to use. It's not like we can always guarantee that the properties
are there anyway since memory allocation in constructing the message may
fail, etc.

> 2) Adding/removing methods, properties or whole interfaces while object
> is already registered may require quite heavy code modifications.

Agreed, I do not really want to change the properties registered on an
object or introspection data. I'm only trying to understand what harm is
there in some objects not providing all of the properties.

-- 
Jouni Malinen                                            PGP id EFC895FA