Quoting Manuel Naranjo <[EMAIL PROTECTED]>: >> Do I see this correctly that the DBus-API can only handle File-I/O as local >> source/target? Is this normal for DBus? > What do you mean?
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? Some may want to have the obex storage in a database or whatever you can imagine. However, sending the whole data over DBus might be horribly inefficient as it is intended for messaging, not for data streaming. SharedMemory comes to my mind for that. 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 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. 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). 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
