Hi Hendrik, On Wed, Sep 15, 2010, Hendrik Sattler wrote: > We could use the cached results. However, almost every documentation I > saw (on other systems, nothing for Bluez) suggests not to do that as > the cache may contain devices that are not in range anymore. Using the > cache can give you strange and unpredictable results (e.g. devices in > range but not in cache and the other way round).
True. I was referring more to the cached name and device class. Another problem that the API will have is that many people pair their devices once and then switch them permanently back to hidden mode. I.e. you wouldn't catch these by doing inquiry anyway. E.g. in Maemo/MeeGo the device discovery UI always shows paired devices (no matter if they're discoverable or not) and then below them other devices that were discovered through inquiry. This speaks imo in favor of letting a platform specific UI handle the discovery and device selection and not try to have the functionality on the openobex side. > The name function already gets it from the cache if it is there. At > least it seems to do that. Not sure how you've come to that conclusion. If you look at lib/hci.c in bluez you'll see that all the function does is send the HCI command to the chip and then wait for the reply from it. I.e. a baseband connection is always inevitable. > Bluez is highly under-documented, the doc/ sub-directory in bluez > source just contains d-bus api docs. What if I do not want to use > d-bus? That's the only API that's really recommended for use by applications in use cases like this. It could of course be wrapped e.g. into a C library if you want to hide the fact that D-Bus is being used behind the scenes. If D-Bus is strictly out of the question (i.e. can't even be present on the system) then you can't really use BlueZ at all since it's a hardcoded dependency. > The functions from libbluetooth have _NO_ documentation with them! Yep. This is something I can't take too much blame for though since I joined bluez developent long after this API was implemented ;) > If there is another way to get the address, name and class of devices > in range, please show me :) I'd rather do it right and properly > documented in openobex instead of having x applications doing it wrong > in their way. I'd expect most devices with Bluetooth not to restrict themselves only to OBEX based profiles and in that case they'd need to implement device discovery themselves anyway. Johan ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
