On Mon, 2 May 2005, Marcel Holtmann wrote:
I am mostly fine with all your changes, but "struct usb_obex_intf" worries me a little bit. Is it possible to create a string from it that represents all the needed information and hide all other stuff inside the USB transport layer. From my current view I think the OBEX API should be as simple as possible. So less structs are better.
You need to supply at least a USB device/interface pair, and I don't think you can identify that with a string. So there has to be a struct.
I think the API can be simpified by introducing a grand unified transport connect function, which hides all the transport-specific data inside struct obex_transport:
int OBEX_TransportConnect(obex_t *self, struct obex_transport *transport);
and then marking all the transport-specific functions as deprecated.
Another thing is that the different transport layers should be loaded on demand by dlopen() and realized as plugins. The dependencies with the USB and Bluetooth libraries are maybe too complex for some systems.
It's unlikely we'll get yet another transport in the near future, so maybe we can keep things in a current, static way for now.
Alexander
Homepage: http://www.sensi.org/~ak/
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
