[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] API's
> Well being a newbie to Bluetooth I've few doubts. In the stack the
> lower layer line baseband ,LMP, L2CAP talk to each other through
> primitives but how does RFCOMM talks with say OBEX ? Is it that only one
> has to establish the connection read or write into the ports and
> disconnect or do we have to do some thing other than this ?
I've been thinking about an API as well in the last few days, and maybe
even a library to make things easier to use. To do this one has first to
identify the functions needed by upper layers (I'm thinking of
inquiry&co. pairing/bonding, registering server with RFCOMM,
opening/closing RFCOMM connections, registering SDP entries, querying
SDP entries and the like).
For applications using the serial port emulation the devices ttyBT* are
used and so there is no problem with references to the driver to access
these functions. But what about other applications. For example,
shouldn't there be a device allowing access to the SDP server (which is
unique in each device).
We may be able to set up a web page to resume a bit ideas and discuss
these issues on this list, because in my opinion the stack has to become
a little bit more generic and shouldn't have to care to much about the
profiles used (e.g. doesn't need to distinguish them as it does in sdp.c
at the moment), but just provide the services to use a given profile.