Quoting Manuel Naranjo <[EMAIL PROTECTED]>: >> It can only send from files and store incoming data to files. However, >> that is not the only way to do things, especially for OBEX. >> Imagine a desktop like KDE or Gnome as a whole: incoming with MIME >> type text/vcard could go directly to the storage location (whatever >> format that is) of the addressbook application instead of first to a >> temporary file and read again from there. Same for other MIME types. >> Can two programs can the data from one OBEX instance? If yes, who >> actually deletes the file from disk? (race condition?) Or is it stored >> multiple times to disk, once for each DBus client? > AFAIK you can't do that, received stuff goes straight to a file. Anyway > what's wrong about having intermediate files.
If that's the concept of that tool, they are fine. Still some kind of work-around in my eyes. >> I am really in favour of DBus for messaging but using that for >> virtually everything doesn't sound right to me. Or maybe I failed on >> the concept of >> obex-data-server and it is only a normal obex server that allows >> notification of DBus (that would be good). >> > The idea behind obex-data-server and the bluez dbus binding is that the > programmer doesn't have to worry much about bluetooth internals or bluez > internals. That's done via signals, that's it. Neither does any obex client software that doesn't use DBus. The only bluetooth thing that it needs are SDP lookups. >> The DBus calls to open client connections interrupt this POV, though. >> There is just no benefit over calling library functions (except a >> horrible overhead, here DBus communication). >> Same for bluetooth: why do you think using DBus directly is better >> than using libbluetooth? The latter is backwards compatible and can >> also do the DBus thing if implemented so. >> > libbluetooth is going to change with bluez 4, you might not be able to > access to the hci commands any more. Again the idea behind using dbus is > not having to struggle with bluetooth internals any more. You have to struggle with DBus internals instead. What an advantage (see below) :-( The C (no GLIB!) interface to DBus is easy to use? Additionally, you loose all backwards-compatibility if no wrapper library (libblueooth) is provided by the bluez project. I really hope they do provide that. >> To sum it up: as a normal server with notification support, this is >> good. However, the DBus support for being an OBEX client should be >> ripped out ASAP as it represents a VERY wrong idea for what DBus >> should be used for. Instead, offer a library with bindings that has >> such an easy-to-use interface (and that lib doesn't need DBus for >> anything) > This project is at it's first stages, the first version is 0.1, so it > has a long way to go yet. D-Bus has been proving to be the right way to > go for BlueZ it's development has become much easier and lots of user > applications are been created. How many of those DBus-using applications are written in plain C without using GLIB? I cite from http://dbus.freedesktop.org/doc/dbus/api/html/index.html: "This manual documents the low-level D-Bus C API. If you use this low-level API directly, you're signing up for some pain." Is this really your suggestion? > About the over head it doesn't make any difference, I have it running on > a machine with 200Mhz and works pretty well, the overhead is non > noticeable and take into account I'm using python as scripting language > to take control over it. The really do suggest using the Glib binding when programming in C. Do they know how big this thing is? That's insane! A C++-API without some putNameOfBigLibraryHere? Didn't find one. To me it looks like as if DBus guys are basicly targeting Gnome and KDE programmers, or programmers for Languages like Python that have an Object Class Model. I'd rather struggle with HCI functions, then. HS ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Openobex-users mailing list [email protected] http://lists.sourceforge.net/lists/listinfo/openobex-users
