> 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. > 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. > Indeed D-Bus is not intended for such large data transfers.
> 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. > 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. > 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. 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. ------------------------------------------------------------------------- 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
