Zitat von "Johan Hedberg" <johan.hedb...@gmail.com>: > 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.
I'll put that into obex_find app directly then. Does that sound reasonable to you? > 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. libdbus API documentation (at least they have one) starts with "If you use this low-level API directly, you're signing up for some pain." Not too convincing :-( and looking at the API, I agree to that statement. So either I use _horrible_ libraries like GLIB or what else? I cannot interface with the bluetooth system then? Maybe we should stop writing libraries and only use d-bus. Bind openobex to obexd (it already misuses the openobex name space in d-bus instead of its own) and be done with it. >> 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. I don't have such a "device". I am on a standard computer. And sometimes on another that doesn't run Linux. "hcitool scan" scans addresses, and to check the dev_class, I have another call. Then I use sdptool. That does exactly what you consider bad and time-consuming. But I have to for almost all available tools, e.g. obexftp. HS ------------------------------------------------------------------------------ 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
