Hello Santiago! 2010/5/7 Santiago Carot-Nemesio <scarot@xxxxxxxxxxxx>: > Hi João Paul, > > El vie, 07-05-2010 a las 15:25 -0300, João Paulo Rechi Vita escribió: >> Hello Jose! >> >> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@xxxxxxxxxxx> wrote: >> > Hi José, >> > >> > * José Antonio Santos Cadenas <jcaden@xxxxxxxxxxxx> [2010-05-07 13:02:36 +0200]: >> > >> >> Hi all, >> >> >> >> I start this thread to discuss the alternatives to move the data from the >> >> application to the l2cap socket in HDP. Till now we have the following >> >> alternatives (please, add more if we missed something) >> >> >> >> Reconnections options: >> >> >> >> Option 1: Implicit reconnections: The application is not concern about the >> >> disconnections or reconnections of the data channel until it is deleted. >> >> >> >> We prefer this option because fixes more with a manager philosophy. A >> >> 20601 manager sould not perceive temporal disconnections because this way can >> >> hold it state if it perceives a disconnection, next time it reconnects it will >> >> need to exchange again apdus for association. >> >> >> >> Option 2: Reconnections by the application. The applications are notified when >> >> a data channel is disconnected and should perform a reconnection before using >> >> it again. >> >> >> >> The HDP Implementation Guidance Whitepaper clearly states that >> transport (HDP) disconnection / reconnection should be transparent for >> the data layer (IEEE 11073-20601), so I guess option 2 here would >> break the spec. > > You're rigth, we consider that option 1 is the best approach. But it's > better try get consensus ;) > In addition, option 2 pass MCAP logic to application layer > (connection-reconnection), and 11073-20601 should be independent of such > transport specific characteristics. > My main concern here is not about which one is the best approach, but about specification-compliance. Sometimes we may want to deviate a bit from the spec if this provides a big performance gain or so, but it has to be evaluated with much caution, since it can compromise qualification with the Bluetooth SIG (on some cases for the whole stack). I may have misread the spec and it might have left this approach 2 as an option, so please correct me in this case. But if not, I guess approach should not be considered. -- João Paulo Rechi Vita http://jprvita.wordpress.com/ -- 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
