Hi Hendrik, On Thu, Sep 16, 2010, Hendrik Sattler wrote: > > 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?
Yes. > > 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. I know. Whenever possible direct contact with the low-level libdbus library should be avoided. However more generally I don't think it'd be a good idea to add a D-Bus dependency to libopenobex at all. > So either I use _horrible_ libraries like GLIB or what else? The libgdbus which is about to be included the next GLib release is apparently much better the the older dbus-glib. However as I said I don't think libopenobex should get any kind of D-Bus dependency. > I cannot interface with the bluetooth system then? The easy (lazy) answer is not to add this functionality to libopenobex at all. What could make sense though is for BlueZ to export a library which abstracts direct access to its database of cached device information. It already exists in a way internally in BlueZ through src/storage.c. > I don't have such a "device". I am on a standard computer. Eh? A standard computer will never want to use non-OBEX based profiles? What about Bluetooth headsets/speakers or HID devices? Even if you'd never use them they're quite a common Bluetooth use case for PC's. > "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. I guess the main issue is that there really isn't any convenient and universial C based D-Bus library. If you were writing in any other language the situation becomes quite different. E.g. with python you don't need many lines of code to discover devices, pair a device, discover services and connect to a specific profile. Also, all of the command line tools you mentioned could (and likely will) be replaced by very similar command line tools which behind the scenes talk D-Bus to bluetoothd. The main reason why this doesn't exist yet is just lack of time and prioritization to implement it. 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 [email protected] http://lists.sourceforge.net/lists/listinfo/openobex-users
