Hi Kim: Thank you very much for carefully investigate on NTB, and give out the valuable feedback. I think it is a very good technical discussion. We are very glad talk on it. Let’s go through these topics one by one. * Bluetooth CAPI (bluetooth.c) is a library to be called by applications. To the best of my knowledge, a shared library cannot share the data section between different processes. In my opinion, current implementation has not considered this. [Martin]Yes, you are right, NTB is using shared library, and shared library can’t share section between different process. But I do not think it is a problem here. Firstly, our design philosophy is to provide all Bluetooth service through unified Tizen Core API interface, I think that is also the overall design requirement from Tizen. Secondly, I can’t understand why different processes need to share data. If you want to share data vconf can be used, besides at BlueZ and Bluez-lib layer also maintain the Bluetooth states, so different processes can easily access/share the same Bluetooth status. Lastly, so as to the bt-initialize(), I think it is the right design, The basic concept is using Bluetooth, you need to initialize it, and need not care about whether some other process and the Bluetooth statues, Bluetooth-framework will handle everything. That is the most easy way for application writer. Besides, that CAPI should be compatible with the original design. But I am still keep open on this topic, if you still think it is a issue, please give me more examples, we can continue to discuss on it. :)
· Error and Exception Handling [Martin]we already start to work on it. Thanks for your input. · memory consumption design goal. The memory consumption of current bluetooth-frwk is a result when hfp/share was enabled, but I think the new design did not enable them. [Martin] I believe we can reach the design goal in the end. You are right, we got the memory consumption data expectation without HFP support basing on prototype(you know, according the plan decided by “Intel and Samsung comms team”, Samsung will enable tizen-2.x HFP which is based on Samsung’s telephony stack). But the expectation is reasonable, we did not enable HFP, but at the prototype, we also do nothing on the memory consumption optimization, as I mentioned before, we used gobject which consumes a lot of memory. Removing gobject and other memory consumption optimize work will be done in next stage. After all of the work be done, I believe we definitely will reach the goal. Thank you very much for pointing out the runtime load module and plugin, that is the missed implementation in the design, we will work on it. · Reduce maintaining efforts [martin] I believe, both of us agree that this design will make the big version upgrade very easy, after we introduce the bluez-lib design, all the upgrade work will focus on very limited files. I’d like to emphasize that we can’t expect that there will no big change anymore. Upstream always claim to keep stable of API, but they always kept changing the API. Besides, even the small change of BlueZ API, we also can get benefit especially to people not familiar with the code. Compared with the original design Current design is simple and the code is more easy to be understood and easy to maintain. · Stabilization [Martin] we spend a lot of efforts to pass the TCT, and you know, according to our last f2f meeting, pass TCT test is the stabilization criteria requirement from Samsung. In fact we have done a lot of test on it. So if you think that is not enough, please let us know what other test your want us to pass? Summary: [Martin]I believe NTB is a good design and can help improve the Tizen Bluetooth framework from many aspect, like memory consumption, maintain efforts, and unified interface. At same time we are open to any suggestion and proposal as well as patches, since it is purely an open source project. besides, I think we may meet some issues when integrate that into Tizen-3.0 and Tizen-2.x. We will actively work on any issues. if you met any issues, please let us know. And the NTB develop work is still ongoing, we just finished the main features, and pass the TCT test, now we are work with Dominique’s team to add multi-user support and integrate NTB into Tizen-3.0. And besides, the next stage work is in also in plan, like memory consumption optimization work, and other potential new features. We really need the your input and feedback on NTB, that is really important to our work. Lastly, according to your feedback, below work already started. 1. “Error and Exception Handling fix”. It will be finished within two weeks 2. “Runtime plugin and module load/unload” it will be finished within two weeks I hope that can answer your question, any issues, please let me know. :) Thanks! From: Xu, Martin Sent: Wednesday, October 29, 2014 14:19 To: Zheng, Wu Subject: RE: [Dev] [Bluetooth] About NBT Hi Kim: Thank you very much for carefully investigate on NTB, and give out the valuable feedback. :) But I think it should not be the “issue” at all, instead, it should be the purely technical and design discussion. In fact, in the past year, Samsung Comms team, Intel comms team have already a lot of discuss on it. I still very happy to answer your questions, Let’s go through your issues one by one. * Bluetooth CAPI (bluetooth.c) is a library to be called by applications. To the best of my knowledge, a shared library cannot share the data section between different processes. In my opinion, current implementation has not considered this. [Martin]Yes, you are right, NTB is using shared library, and shared library can’t share section between different process. But I do not think it is an issue here. Firstly, our design philosophy is to provide all Bluetooth service through unified Tizen Core API interface, I think that is also the overall design requirement from Tizen. Secondly, I can’t understand why different processes need to share data. If you want to share data vconf can be used, besides at BlueZ and Bluez-lib layer also maintain the Bluetooth states, so different processes can easily access/share the same Bluetooth status. Lastly, so as to the bt-initialize(), I think it is the right design, The basic concept is using Bluetooth, you need to initialize it, and need not care about whether some other process and the Bluetooth statues, Bluetooth-framework will handle everything. That is the most easy way for application writer. Besides, that CAPI is totally compatible with the original desing But I am still keep open on this issue, if you still think it is a issue, please give me more examples, we can continue to discuss on it. · Error and Exception Handling [Martin]we already start to work on it. Thanks for your input. · memory consumption design goal The memory consumption of current bluetooth-frwk is a result when hfp/share was enabled, but I think the new design did not enable them. [Martin] I believe we can reach the design goal in the end. You are right, we got the memory consumption data expectation without HFP support basing on prototype(you know, according the plan decided by “Intel and Samsung comms team”, Samsung will enable tizen-2.x HFP which is based on Samsung’s telephony stack). But the expectation is reasonable, we did not enable HFP, but at the prototype, we also do nothing on the memory consumption optimization, as I mentioned before, we used gobject which will consume a lot of memory. Removing gobject and other memory consumption optimize work will be done in next stage. After all of the work be done, I believe we definitely will reach the goal. :) Thank you very much for pointing out the runtime load module and plugin, that is the missed implementation in the design, we will work on it. · Reduce maintaining efforts [martin] I believe, both of us agree that this design will make the big version upgrade very easy, after we introduce the bluez-lib design, all the work will focus on very limited files. I’d like to emphasize that we can’t expect that there will no big change anymore. Upstream always claim to keep stable of API, but they always kept changing the API. Besides, even the small change of BlueZ API, we also can get benefit especially to people just access the code. In the original design all the BlueZ will go through Bluetooth-service and Bluetooth-service then call the blueZ, and the code is difficult to understand, and difficult to debug and difficult maintain. · Stabilization [Martin] we spend a lot of efforts to pass the TCT, and you know, according to last f2f meeting, pass TCT test is the stabilization criteria requirement from Samsung. So if you think that is not enough, please let us know what else test your want us to pass? Summary: I believe NTB has resolved a lot of issues in old design, please _do_ not just focus on some specific design expectation data, please have a look at the design and implementation itself. :) Besides, I believe, when integrate it into Tizen-2.x especially add some Tizen-2.x features, will definitely meet some issues. Just like we adding multi-user support when integrate it into Tizne-3.0. So I am very happy to help you on it. if you have any issues, please let us know. Thanks! From: Xu, Martin Sent: Wednesday, October 29, 2014 14:12 To: Zheng, Wu Subject: RE: [Dev] [Bluetooth] About NBT om: Dev [mailto:[email protected]] On Behalf Of ??? Sent: Monday, October 27, 2014 7:50 To: Dominig Ar Foll Cc: [email protected]<mailto:[email protected]> Subject: Re: [Dev] [Bluetooth] About NBT Hi Mr. Doming ar Foll, I'm not proposing something for NBT. I shared these issues with Mr. Zheng before, but he didn't agree on these issues. So, I'm sharing the issues in here and expecting to get your opinion. Regards, Seungku Kim ------- Original Message ------- Sender : Dominig Ar Foll<[email protected]<mailto:[email protected]>> Date : 2014-10-26 08:42 (GMT+09:00) Title : Re: [Dev] [Bluetooth] About NBT Kim, interesting report. Could you please let us know what you have proposed to Zheng ? As your chat were private so far, it's not easy to see how we can help. BT-NG has announced the integration of Multi user support last week and for that reason is of high interest for Tizen 3, nevertheless it also has to work well for all usages in Tizen 3. Regards 2014-10-24 7:05 GMT+02:00 김승구 <[email protected]<mailto:[email protected]>>: Dear all, I'm raising some issues about NBT (Next-generation Bluetooth). Please find an attached file. I and Mr. Zheng Wu have already discussed about these issues, but we couldn't find common ground for these. Please give any idea of this issue reporting. You can see concept of NBT at the below link and code of NBT at "devel" branch of bluetooth-frwk. https://wiki.tizen.org/wiki/NTB_Architecture * Issue summary 1. CAPI implementation problems 2. Error and exception handling 3. NBT's expected performance Regards, Seungku Kim [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=14f7afe1216e96748ff2d639893d17fffa74e16b7669935f5f39fdc1fff954953c40f787d33f357d2a25309f192153c249e5ff3dfdc8681d76f80bf81d31c863cf878f9a26ce15a0] _______________________________________________ Dev mailing list [email protected]<mailto:[email protected]> https://lists.tizen.org/listinfo/dev -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre [cid:[email protected]] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=14f7afe1216e96748537d18f8017650a90c85c76f7a592605f39fdc1fff954953c40f787d33f357d2a25309f192153c249e5ff3dfdc8681d76f80bf81d31c863cf878f9a26ce15a0]
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
