Hi, I think it`s a good idea to create a new API : FdOBEX_SetTransportFormat. I`ll update my patches in new mails. -----Original Message----- From: Hendrik Sattler [mailto:post@xxxxxxxxxxxxxxxxxx] Sent: 2011年6月21日 4:44 To: openobex-users@xxxxxxxxxxxxxxxxxxxxx Cc: Marcel Holtmann; Li, Nami; Liu, Haijun; linux-bluetooth@xxxxxxxxxxxxxxx Subject: Re: [openobex-users] [PATCH openobex 1/3] Add transport format member in fdobex_data struct. Support STREAM and SEQPACKET transport format. Hi, Am Montag, 20. Juni 2011, 21:45:11 schrieb Marcel Holtmann: > > > > include/openobex/obex_const.h | 4 ++++ > > > > lib/fdobex.h | 1 + > > > > 2 files changed, 5 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/include/openobex/obex_const.h > > > > b/include/openobex/obex_const.h index cb7afeb..8acee91 100644 > > > > --- a/include/openobex/obex_const.h > > > > +++ b/include/openobex/obex_const.h > > > > @@ -302,6 +302,10 @@ enum obex_rsp_mode { > > > > > > > > OBEX_RSP_MODE_SINGLE = 1, /**< single response mode (SRM) */ > > > > > > > > }; > > > > > > > > +enum fdobex_transport_format{ > > > > + FDOBEX_MT_STREAM , > > > > + FDOBEX_MT_SEQPACKET > > > > +}; > > > > > > can I ask again why we should be doing this. Especially for the > > > FdOBEX transport this is pointless. You are getting a file > > > descriptor in the first place. It does not have to be a socket. > > > > > > And in the case this is really a socket, then you can just use > > > SO_TYPE to read the current type of the socket. > > > > > > If it is not a socket, then it needs to treated as stream anyway. > > > > No. Ever tried that on the linux USB gadget implementation in Linux? > > If a FD is not pointing to a socket, it can still point to a device > > file of whatever kind. You SO_TYPE won't completely help here. You > > can try any amount of guessing but isn't it easier if the > > application just tells you? OTOH, the application could just use a custom transport, then. > > problem is that either we introduce a new abstraction or we figure > this out magically. Breaking the API like this is not a good idea. > > So if we go for FdPacketOBEX or something it might be a possible > option, but breaking FdOBEX API is not an option. How about a new function: void FdOBEX_SetTransportFormat(obex_t *self, enum fdobex_transport_format fmt); Should not break anything :) HS ?韬{.n?????%??檩??w?{.n???{饼?z????n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
