Re: [openobex-users] [PATCH openobex 1/3] Add transport format member in fdobex_data struct. Support STREAM and SEQPACKET transport format.

[Marcel Holtmann <marcel@holtmann.org>]

Hi Hendrik,

> > >  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.

Regards

Marcel