Hi Kis: Thanks for your comments on NTB, and in general, we have same opinions from technology. Please see my comments. > On Fri, Nov 14, 2014 at 12:17 AM, Xu, Martin <[email protected]> wrote: > > Patrik: > >> Subject: Re: Intel Tizen Architecture & Leads meeting - 2014-11-11 > >> > >> On Thu, 2014-11-13 at 20:47 +0000, Xu, Martin wrote: > >> > Hi: > >> > I am sorry, maybe I made people in the meeting misunderstand the > >> > states of > >> NTB Multi-use support. > > Patrick: > > I agree with you, that Multi-user is not easy. So I mentioned that we will > continue to work with BlueZ upstream and Dominique team on this task. > > And currently, the phrase 1 is just purely handled from NTB side. > > And we base on the Tizen Application framework(Native Framework, Web Run > Time Framework) design, that Bluetooth service should be accessed through > CAPI. > > > > And I do believe we can work with BlueZ upstream to find a overall > > final solution. But that need time and efforts, and need to do it step > > by step, right? :) > > As for the daemon, I think enabling multi-user and other use cases should be > implemented in upstream BlueZ if possible, instead of replicating the whole I totally agree with you that multi-user should be implemented by upstream. However you know since 1. BlueZ now does not support multi-user. 2. Bluetooth Framework(Old and NTB) does not include multi-user feature from beginning. So after evaluation we found we can only support phrase 1 feature in NTB https://wiki.tizen.org/wiki/Multi-user_Bluetooth basing on the concept that Bluetooth service needs to be acquired from CAPI.
And in the long run we must work with upstream and Tizen common team to find the right Solution for the other phrases multi-user features. > functionality of BlueZ in a new demon/API (which will still take a lot of > time), and then adding those missing features. Or find a way to add only the > missing functionality and also use BlueZ instead of replicating most of it. You give another very good point. The design goal of NTB is to just to use BlueZ directly and _not_ through a daemon. (You know old Bluetooth framework will proxy all the request to BlueZ) And most of the things should be done at BlueZ. However the reality is that we have to handle some Tizen specific work that can't be Push into BlueZ upstream. And It is also very difficult to change the existing Tizen. So what we can do is to put this work into Bluetooth service daemon. I can give you 2 examples. 1. Paring, Samsung Home UI using the plugin to request paring. When user open "setting" and entering the "Bluetooh paring page", the plugin will be loaded by setting UI then user can operate on the paring, but once user leave the "paring UI" the plugin will be unloaded. Then BlueZ get to know that the paring user has disconnected from Dbus, all the following Bluetooth operation will be cancelled by BlueZ. And Bluetooth can be used anymore. So from technology, there are two right ways to resolve the issue: 1)disable the disconnect check from BlueZ. I have submitted patches to upstream, but that is rejected. Marcel clearly tell me he will not accepted the patches 2) modify setting UI. Samsung clearly to say no to us. So the only thing we can do is to add paring relay module in NTB service to handle the paring. 2. OPP file transfer notification Tizen support the notification to indicate people the percentage of file transfer. But that is done through Tizen notification API, and it is impossible for BlueZ upstream to use the Tizen API directly. so the OPP module in NTB service needs to monitor the dbus message >From BlueZ and use notification API to notify the file transfer percentage. There are still a lot of other reasons why we have to use Bluetooth service like the vconf setting. But as I said I hope these Tizen specific as little as possible, So I design individual function as a module. And the module can be load/unload on demand. So if some platforms like IVI does not need some functions, the related Module need not be loaded and CAPI should talk directly to BlueZ, And the best case is that all the functionality should go directly to BlueZ, That is what I want. But we need to investigate the requirement on each platform to figure out the detail. And configure for different platform. The loading/unloading module is ongoing, and the CAPI route to BlueZ is also in plan. > The bigger problem is that CAPI [1] does not support the features promised > in the architecture slides [2], so it is impossible to be used in Crosswalk > extensions using PBAP and MAP for instance. Instead we need to directly use > BlueZ, and that is what I am doing now. Please tell me detail what is the features promised in CAPI and not supported? And what is the detail about why you can't use PBAP and MAP? So here I want to introduce another design goal of NTB: All the Bluetooth service should go through the unified interface. Of course Best option is to use BlueZ dbus interface. But during past 6 years working on Comms projects like (BlueZ/ConnMan/oFono). I got to know that it is not easy to use Dbus. in order to use Dbus interface, People has to know the dbus programming, and a lot of extra program work needed. So I designed the BlueZ-lib which just provide the BlueZ interface from C lib wrap the Dbus operation, and People do not need to write their own Dbus code to access BlueZ, that save a lot of efforts. But after I try to push that to Tizen. I was told that Tizen must use CAPI. And frankly say, I do not think current CAPI is good enough, so I try to work on design The new CAPI. But that was strongly rejected by Samsung, They asked us to strictly compatible with current Tizen CAPI, and request NTB to go through TCT(Tizen Compatible Test). In the end we decide that at first stage we will try best to compatible with the current CAPI, And at following stage we will work on the optimization of the new CAPI. So from the code you will find that there are BlueZ-lib which maps BlueZ API and CAPI implementation. Because some of CAPI is designed for BlueZ-4.x and not applicable to BlueZ-5.x so we have to change Some CAPI, that change has been reviewed and accepted by Samsung and we also have included the change into wiki page. So go back your question that you will directly use BlueZ. From technical, I can't say it is not right. But from Tizen, I am not sure whether we can break the rule to use CAPI. I need someone to clarify that. And I also suggest to have look at bluez-lib in NTB, that even can help you if you want to direct call BlueZ-5.x. :) > > It is not clear what is the plan and schedule for full functionality support > in the CAPI, but this should be a central element of your plans, otherwise > it would be pity to develop a whole new framework with great effort, then > enforce using only that one, just to learn developers suddenly can't use > half of Bluetooth related functionality any more. I do not know what is your meaning of full functionality support in CAPI? >From the wiki page you should know that we have passed TCT test pass rate >98.13%(322 test case and 314 passed) And nearly all the CAPI has been supported. What missed is HFP(since that is related with Samsung telephony stack, so we ask Samsung to handle it) And Bluetooth LE GATT, and client is ready, we are working with BlueZ upstream on the Server features. > > May be my limitation, but after reading the architecture doc, it's still not > clear to me why are you replicating BlueZ, instead of extending it where > needed, unless you want to make BlueZ entirely replaceable with other stacks > (but then it's not clear why not cut from the CAPI, since one would need to > rewrite [parts of] the NTB as well in that case). It also has omissions, e.g. > HFP support comes from ofono and that's not in the picture. In any case the > architecture doc needs clarifications and corrections. We will try best to add more into the wiki page. But it is very difficult to put everything in it. Some of information need to be get from code or from here. :) I want to repeat here, I do not intend to replicate BlueZ, instead I want to resolve that issue in old framework. So as to HFP, telephony stack oFono, that is long story, It is us to persuade people to push oFono into Tizen and used by IVI. And we also every did huge of work to enable the whole telephony stack based on oFono for Tizen. Using OFono, most of related HFP CAPI is not necessary, you know oFono and BlueZ as the same level of Comms service, they talk directly to handle the HFP function. And UI can talk with oFono to handle HFP functionality. Now we are also work with Tizen common team on it. And your suggestion is good, we will add the HFP related contents into wiki page. > > For a better approach, I would like to see a study listing the use cases, > diff vs upstream BlueZ, architecture, deployment and implementation options > analyzed, and the technology choices clearly documented. Right now this > looks just like a refactoring of the old Bluetooth framework (i.e. only part > of the work needed), but we need more than that IMO, once security related > enforcements are in picture. I agree with you, And as a brand new framework, we still have many work to do, and now, it is only 0.2 release. but we need to do the work step by step. And from technology I did not find any different view between us, I just hope you can know the reason Why we use current solution, and what is the right solution and plan for future release. The technical discussion, and design review has go through several round, as an open source project I am very very glad to hear any suggestions here. I also quite happy to see the patches. :) I hope my above comments can answer your question. Thanks! _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
