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 > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
