[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#528061: ITP: obexd -- OBEX client and server

Zitat von Filippo Giunchedi <filippo@debian.org>:

On Sun, May 10, 2009 at 09:15:19PM +0200, Hendrik Sattler wrote:
> The obexd is an attempt to unify all current OBEX based servers for

No, it isn't. It's another implementation.

Implementation of OBEX client and server as a D-Bus service providing high-level

sounds better?

Yes. :)

> Linux and create a small, but powerful daemon.
> [taken from upstream http://www.bluez.org/obexd-01/]
> I'll package this under pkg-bluetooth
> http://svn.debian.org/wsvn/pkg-bluetooth/packages/obexd/

What is the difference to obex-data-server?

e.g. ods changed API between 0.3 and 0.4, bluez-gnome 1.8 supports ods 0.3 and obexd AFAICT.

And upcoming kdebluetooth4 uses solid which require bluez 4.x and (latest) obex-data-server (that's what I read about it).
Bluez-gnome 1.8 is "crippled" when not used with bluez 4.x.
I doubt obexd runs with anything but bluez 4.x.

And bluez 4.x is not in unstable, yet. Hmm.

Also the two use different dbus org.openobex APIs which I'm currently not sure what is the recommended one, see

That one gives no answers. I'm lazy comparing both APIs but they use the same dbus namespace and thus cannot run in parallel. Both upstream, from obexd and from obex-data-server, should be contacted to clarify that. The decision should not be forwarded to the users and they simply won't know. And having kdebluetooth4 using ods while bluez-gnome uses obexd only makes it worse.

If they use the same dbus API, they should share the same virtual package and the decriptions for both should state the OBEX profiles that they support (for obexd this is OPP and FBS). Both are in active development.

Please also take into account that bluetooth is not only used with bluetooth transport but also with IrDA, USB, TCP and possibly serial cables. Obexd only supports bluetooth, AFAIK. obex-data-server also supports USB, AFAIK.

I would like to avoid the same mess as we had with bluez 2.x -> 3.x transition where there were no usuable frontends until much later. So the whole thing should be polished including packaging of kdebluetooth4.


Reply to: