A very simple session graph that illustrates the proposed API can be seen at http://epx.com.br/health_bluez.png.
This API proposal was discussed jointly with Claudio Takahashi, Vinicius Gomes, Raul Herbster and others, and it is based on previous work on MCAP API specification by Jose Cadenas and Santiago Nemesio, which have been CCed.
The main guidelines of our current proposal are:
a) MCAP is just a protocol, which does not specify SDP records for its own needs. The HDP profile specifies the necessary SDP record, so we expose an API for HDP, not for MCAP.
b) Avoid exposing MCAP protocol details to the API client, except where unavoidable. Several MCAP parameters like PSM control channel may be left undefined by the client, and the implementation would fill them with reasonable values.
c) MCAP control connection (MCL) is completely taken care of. The application only deals with MCAP data channels (MDLs), if any.
d) The application should not need to handle SDP records, which are quite complicated in the HDP case. When it registers a HDP role, enough information is passed so a SDP record may be published automatically.
When a remote HDP device is present, its SDP record would be interpreted automatically, so the application can discover easily the MDEP IDs and data types offered by remote device.
e) The API allows for active connection, but still the application must register the HDP role beforehand. This ensures that a proper SDP record will have been published. (HDP sinks, the most common role a BlueZ-running device will play, require the SDP record).
f) HDP would be implemented inside bluetoothd as a plugin.
g) HDP itself does not specify the data channels' protocol (it is normally the IEEE 11073-20601, but there may be others in the future). The API client would receive L2CAP sockets for each data channel, and select()/recv()/send() them directly.
h) The application would be responsible by keeping the relationship between MDL IDs and IEEE sessions, if it wants to enjoy the reconnection feature. Also, it needs to be prepared to have a MDL socket closed, receive another one and continue the session over it.
If the application does not want to deal with reconnection, it may ask for MDL deletion upon socket closure, or just take the new socket as a brand new MDL.
The HDP plugin would keep the necessary state information (local and remote MDEP IDs) to allow easy (and transparent) reconnection.
Cadenas and Nemesio have already sent patches with an initial MCAP implementation, some time ago. We hope to build on their initial effort and collaborate with them in order to have HDP implemented as soon as possible and offering a very comfortable API for the clients.
--
Elvis
Sorry, Santiago's address was wrong.
Please answer to this mail.
El Friday 30 April 2010 12:59:45 Jos? Antonio Santos Cadenas escribi?:
> Hi all,
>
> El Friday 30 April 2010 04:28:45 Elvis Pf?tzenreuter escribi?:
> > A very simple session graph that illustrates the proposed API can be seen
> > at http://epx.com.br/health_bluez.png.
> >
> > This API proposal was discussed jointly with Claudio Takahashi, Vinicius
> > Gomes, Raul Herbster and others, and it is based on previous work on
> > MCAP API specification by Jose Cadenas and Santiago Nemesio, which have
> > been CCed.
>
> That sounds great. We are happy that our ideas are good for you. We spent a
> lot of time on its desing. If you wish, we can have a meeting early next
> week via IRC or any other way in order to disscuss this api. We have
> already begun working in HDP so it will be very interesting to discuss
> this API with you. We have a quite mature implementation of MCAP. As you
> know, at the current moment we are having an internal reorganiation so we
> have publish an alternative git with the last mcap code (still working on
> it). Please, feel free to download and test it. All comments are wellcome.
>
> git://193.147.51.48/git/mcap_devel.git
>
> If you are interesting in the meeting please consider that in Madrid monday
> is holiday, so the first day that we can talk to you is Tuesday 4th.
>
> > The main guidelines of our current proposal are:
> >
> > a) MCAP is just a protocol, which does not specify SDP records for its
> > own needs. The HDP profile specifies the necessary SDP record, so we
> > expose an API for HDP, not for MCAP.
> >
> > b) Avoid exposing MCAP protocol details to the API client, except where
> > unavoidable. Several MCAP parameters like PSM control channel may be
> > left undefined by the client, and the implementation would fill them with
> > reasonable values.
> >
> > c) MCAP control connection (MCL) is completely taken care of. The
> > application only deals with MCAP data channels (MDLs), if any.
> >
> > d) The application should not need to handle SDP records, which are quite
> > complicated in the HDP case. When it registers a HDP role, enough
> > information is passed so a SDP record may be published automatically.
> >
> > When a remote HDP device is present, its SDP record would be interpreted
> > automatically, so the application can discover easily the MDEP IDs and
> > data types offered by remote device.
> >
> > e) The API allows for active connection, but still the application must
> > register the HDP role beforehand. This ensures that a proper SDP record
> > will have been published. (HDP sinks, the most common role a
> > BlueZ-running device will play, require the SDP record).
> >
> > f) HDP would be implemented inside bluetoothd as a plugin.
> >
> > g) HDP itself does not specify the data channels' protocol (it is
> > normally the IEEE 11073-20601, but there may be others in the future).
> > The API client would receive L2CAP sockets for each data channel, and
> > select()/recv()/send() them directly.
> >
> > h) The application would be responsible by keeping the relationship
> > between MDL IDs and IEEE sessions, if it wants to enjoy the reconnection
> > feature. Also, it needs to be prepared to have a MDL socket closed,
> > receive another one and continue the session over it.
> >
> > If the application does not want to deal with reconnection, it may ask
> > for MDL deletion upon socket closure, or just take the new socket as a
> > brand new MDL.
> >
> > The HDP plugin would keep the necessary state information (local and
> > remote MDEP IDs) to allow easy (and transparent) reconnection.
>
> This is more or less what we think. We believe that is better to talk it by
> IRC. By now he have a sequence diagram with the interaction of HDP with the
> clients (agents or managers).
>
> http://193.147.51.48/hdp_sequence.png
>
> > Cadenas and Nemesio have already sent patches with an initial MCAP
> > implementation, some time ago. We hope to build on their initial effort
> > and collaborate with them in order to have HDP implemented as soon as
> > possible and offering a very comfortable API for the clients.
>
> The patches are now obsolete, because we made a lot of changes on it. We
> haven't sent it yet because we are still waiting for comments about the
> architecture proposed in last patches. It will be better to discard those
> patches. We can also comment/explain the MCAP arquitecture if we have a
> meeting. We are planning to send new patches with all the changes next
> week.
>
>
>
> Regards
>
> Jose and Santiago
>
> PS: Also CCing Pedro de-las-Heras who is also working with us.
>
> > --
> > Elvis
>
Hi all,
El Friday 30 April 2010 04:28:45 Elvis Pf?tzenreuter escribi?:
> A very simple session graph that illustrates the proposed API can be seen
> at http://epx.com.br/health_bluez.png.
>
> This API proposal was discussed jointly with Claudio Takahashi, Vinicius
> Gomes, Raul Herbster and others, and it is based on previous work on MCAP
> API specification by Jose Cadenas and Santiago Nemesio, which have been
> CCed.
That sounds great. We are happy that our ideas are good for you. We spent a
lot of time on its desing. If you wish, we can have a meeting early next week
via IRC or any other way in order to disscuss this api. We have already begun
working in HDP so it will be very interesting to discuss this API with you. We
have a quite mature implementation of MCAP. As you know, at the current moment
we are having an internal reorganiation so we have publish an alternative git
with the last mcap code (still working on it). Please, feel free to download
and test it. All comments are wellcome.
git://193.147.51.48/git/mcap_devel.git
If you are interesting in the meeting please consider that in Madrid monday is
holiday, so the first day that we can talk to you is Tuesday 4th.
>
> The main guidelines of our current proposal are:
>
> a) MCAP is just a protocol, which does not specify SDP records for its own
> needs. The HDP profile specifies the necessary SDP record, so we expose an
> API for HDP, not for MCAP.
>
> b) Avoid exposing MCAP protocol details to the API client, except where
> unavoidable. Several MCAP parameters like PSM control channel may be left
> undefined by the client, and the implementation would fill them with
> reasonable values.
>
> c) MCAP control connection (MCL) is completely taken care of. The
> application only deals with MCAP data channels (MDLs), if any.
>
> d) The application should not need to handle SDP records, which are quite
> complicated in the HDP case. When it registers a HDP role, enough
> information is passed so a SDP record may be published automatically.
>
> When a remote HDP device is present, its SDP record would be interpreted
> automatically, so the application can discover easily the MDEP IDs and
> data types offered by remote device.
>
> e) The API allows for active connection, but still the application must
> register the HDP role beforehand. This ensures that a proper SDP record
> will have been published. (HDP sinks, the most common role a BlueZ-running
> device will play, require the SDP record).
>
> f) HDP would be implemented inside bluetoothd as a plugin.
>
> g) HDP itself does not specify the data channels' protocol (it is normally
> the IEEE 11073-20601, but there may be others in the future). The API
> client would receive L2CAP sockets for each data channel, and
> select()/recv()/send() them directly.
>
> h) The application would be responsible by keeping the relationship between
> MDL IDs and IEEE sessions, if it wants to enjoy the reconnection feature.
> Also, it needs to be prepared to have a MDL socket closed, receive another
> one and continue the session over it.
>
> If the application does not want to deal with reconnection, it may ask for
> MDL deletion upon socket closure, or just take the new socket as a brand
> new MDL.
>
> The HDP plugin would keep the necessary state information (local and remote
> MDEP IDs) to allow easy (and transparent) reconnection.
This is more or less what we think. We believe that is better to talk it by
IRC. By now he have a sequence diagram with the interaction of HDP with the
clients (agents or managers).
http://193.147.51.48/hdp_sequence.png
>
>
> Cadenas and Nemesio have already sent patches with an initial MCAP
> implementation, some time ago. We hope to build on their initial effort
> and collaborate with them in order to have HDP implemented as soon as
> possible and offering a very comfortable API for the clients.
The patches are now obsolete, because we made a lot of changes on it. We
haven't sent it yet because we are still waiting for comments about the
architecture proposed in last patches. It will be better to discard those
patches. We can also comment/explain the MCAP arquitecture if we have a
meeting. We are planning to send new patches with all the changes next week.
>
Regards
Jose and Santiago
PS: Also CCing Pedro de-las-Heras who is also working with us.
> --
> Elvis
>
