Hi Tanu, On Thu, Dec 8, 2011 at 10:53 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > From: Tanu Kaskinen <tanu.kaskinen at digia.com> > > --- > Here is some unfinished work related to the upcoming module > called module-wl1273-support. The module will want to use > the org.bluez.FMRadio interface and get notifications when > the WL1273 chip appears and disappears in bluetoothd. The > module will know the "hciX" identifier of the chip, thus the > fmradios_by_adapter_name hashmap is very convenient for > looking up the right proxy object. > > I'd like to develop bluetooth-util to the direction that > ?* it will hide D-Bus entirely from the modules (except for > ? the async nature of function calls, which can't be > ? hidden) > ?* objects (like Transports and Devices) are directly > ? available in the pa_bluetooth_core struct instead of > ? through the IMO clumsy functions like > ? pa_bluetooth_discover_get_transport() > ?* hooks have very narrow and well-defined semantics, > ? instead of the vague "discovery hook" that seems to be > ? called in strange situations (like as part of error > ? handling when receiving properties...) > ?* objects have clear separation between "public" and > ? "private" variables > ?* things are documented :) > > Please comment if that plan doesn't please you... Im fine with the changes except with this thing with org.bluez.FMRadio, IMO that should belong to the module that requires it beside I don't see us accepting this interface as part of the core daemon, so this probably need to be inside the maemo6 plugin which should only be loaded for its platform. This way we also put pressure in having the hardware/driver exposing everything properly, otherwise it has to do its dirty work themselves. -- Luiz Augusto von Dentz
