Am Dienstag 01 April 2008 schrieb Alex Kanavin: > 2008/4/1, Hendrik Sattler <[EMAIL PROTECTED]>: > > > Well, in an OBEX session one side is a server, and another (the one > > > that issues the OBEX Connect command) is a client, this makes total > > > sense to me. There are many possible use cases for either variant: the > > > simplest is that you can push some files to your phone from your PC, > > > but you might want to push some files to your PC from your phone too. > > > Previously there was no way to know how the roles are assigned for a > > > given USB OBEX interface. > > > > TCP, IrDA and bluetooth are working different, though, as you can listen > > for incoming connections. On USB, you have to inspect any newly attached > > device for that descriptor. Is this possible to get notifications with > > only libusb or is HAL needed? I mean something equal to listen() on a > > socket... > > You need HAL or some OS-specific notification mechanism. Libusb does > not provide notifications for new devices.
Ok. Sad though because I am not a great D-Bus fan :-/ > But the OBEX server/client > roles are independent of underlying transport roles: the other side on > an incoming TCP connection can be an OBEX server or a client. That's not the usual usage model, though, and not directly covered in OpenOBEX (well, you can call the listen() and accept() yourself and play the client role then). Never seen that but hey, anything is possible ;) HS ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users