Re: [openobex-users] OBEX_EnumerateInterfaces API discussion

[Hendrik S. <po...@he...>]

Am Donnerstag 16 September 2010, 20:44:55 schrieb Johan Hedberg:
> > > 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 do not intend to couple openobex with any kind of d-bus. Never, ever :)

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

Yes, what I meant is that standard computers don't have such highly integrated 
bluetooth solution. Except when using... don't know. Not KDE because that 
always gets something new but incomplete. BlueDevil is the 3rd or 4th 
iteration, at least.

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

Maybe I should look into  that :) It's probably rather Qt.

HS