Hi Kevron, NTB(next Bluetooth-Frwk) will care about security and multi-user requirements.
NTB will work with bluez, connman etc upstream. If some requirements of security and multi-user requirements need to be done by upstream, we will talk the topic with upstream to fix them. Best Regards Zheng Wu -----Original Message----- From: Rees, Kevron [mailto:[email protected]] Sent: Tuesday, May 20, 2014 5:35 AM To: Zheng, Wu Cc: Counihan, Tom; [email protected]; Liu, Bingwei Subject: Re: [Dev] New Tizen Bluetooth Framwork (NTB) wiki page A couple thoughts... It seems that in order to enforce security or to do multi-user requires yet-another-daemon and leads to daemon-creep: daemons servicing daemons. Where many of these services are accessed over DBus, the additional DBus-hops has performance implications in addition to memory implications of having yet-another-daemon just to do security. What are the alternatives? Work with bluez, connman, ofono, etc upstream to make the libcynara integration. Make it a compile-time option that's opt-in. I don't know what bluetooth multi-user is. Perhaps use-cases would help people understand what changes need to be made. If there are changes, perhaps the upstream projects would be interested in them also. Upstream first. -Kevron On Mon, May 19, 2014 at 12:50 AM, Zheng, Wu <[email protected]> wrote: > Hi Tom, > > About your questions, > >> Through the wiki, I sense this CAPI is a universal API for all verticals. >>Can someone validate that this is the actual assumption today? > Yes. We design it and hope that this CAPI is a universal API for all > verticals. > >> On an aside note, can someone give more insight into the statement: >> "Some IOT and mobile related features are being developed. > Some IOT and more mobile, IVI related features will be developed. > For matching the related new features, maybe new Bluetooth CAPIs will be > defined too. > >> What I don't know if that decision remains constant or whether there >> is thinking to remove Ofono for this "HFP" agent. > Ofono for "HFP" agent will remains constant on IVI. > >> Reference is made to Connman, which has a similar co-dependency with >> Bluez for its NAP/Panu use cases. > Bluetooth-Frwk will use " Connman " to implement NAP/Panu. > Therefore, Connman will remains constant on IVI too. > > Help that this information is useful. > > Best Regards > Zheng Wu > > -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Counihan, > Tom > Sent: Monday, May 19, 2014 2:59 PM > To: Counihan, Tom; Kis, Zoltan; Xu, Martin > Cc: [email protected]; Liu, Bingwei > Subject: Re: [Dev] New Tizen Bluetooth Framwork (NTB) wiki page > > Any thoughts on the 2 questions below? > > Regards > Tom. > >> -----Original Message----- >> From: Dev [mailto:[email protected]] On Behalf Of Counihan, >> Tom >> Sent: Tuesday, May 13, 2014 11:22 AM >> To: Kis, Zoltan; Xu, Martin >> Cc: [email protected]; Liu, Bingwei >> Subject: Re: [Dev] New Tizen Bluetooth Framwork (NTB) wiki page >> >> Hi Folks, >> >> I would echo Zoltan's request for use cases. >> On the wiki (https://wiki.tizen.org/wiki/NTB_Architecture) I'm drawn >> to the design philosophy section where it states "Unified CAPI for Apps/UI". >> Through the wiki, I sense this CAPI is a universal API for all verticals. >> This is a very key assumption. >> Can someone validate that this is the actual assumption today? >> If so, what I would like help with is, can someone please direct me >> to the analysis that supports this assumptions. >> >> The challenge I face is this. When I focus on IVI, and I look at the >> actual Bluetooth specs - for example: >> HFP 1.6 - >> https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238 >> 1 >> 9 >> 3 >> PBAP 1.2 - >> https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=281 >> 2 >> 99 >> MAP 1.2 - >> https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=274 >> 4 >> 79 >> ARVCP 1.5 - >> https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=260 >> 8 >> 61 >> Etc... >> You will quickly begin to see terminology like "Server Equipment", >> "Client Equipment", "Gateway", "Unit", "SRC", "SINK", "Controller", >> "Target", "Push Server", "Push Client" These are typically contained >> in Section "Configuration and Roles" of each spec. >> >> What I want to impress on folks is, IVI's use cases are not identical >> to say a phones use cases. >> One may argue that for some areas, like OPP the usage could be >> identical - I could buy this, but in this instance the use case for >> both devices would be they implement the use cases of _both_ server and >> client role. >> However, to make this assumption universally I think is something >> that requires particular validation. >> >> That said, it is evident that a lot of work has been done in this >> area. If there is analysis that supports the initial assumption of a >> unified CAPI for all verticals please direct me to same so I can study. >> >> On an aside note, can someone give more insight into the statement: >> "Some IOT and mobile related features are being developed. >> >> HFP " >> >> I would like to know specifically if Ofono remains in focus for this >> work area for HFP use cases. Or whether there is a different thinking. >> My question is specifically in an IVI context where Ofono is used. >> What I don't know if that decision remains constant or whether there >> is thinking to remove Ofono for this "HFP" agent. >> Reference is made to Connman, which has a similar co-dependency with >> Bluez for its NAP/Panu use cases. >> Ofono has a similar co-dependency for HFP. What I don't know if the >> lack of an Ofono statement is more an editorial error or an express design >> decision made. >> >> Warm Regards >> Tom. >> >> > -----Original Message----- >> > From: Dev [mailto:[email protected]] On Behalf Of Kis, >> > Zoltan >> > Sent: Wednesday, May 07, 2014 1:57 PM >> > To: Xu, Martin >> > Cc: [email protected]; Liu, Bingwei >> > Subject: Re: [Dev] New Tizen Bluetooth Framwork (NTB) wiki page >> > >> > Hello, >> > >> > On Mon, May 5, 2014 at 10:00 PM, Xu, Martin <[email protected]> wrote: >> > > All of your questions have been discussed for a long time between >> > > Samsung, >> > upstream(Marcel, Johan, Luiz, you can assume that we are the same team). >> > >> > Perhaps discussed but really agreed yet? I am still missing the use >> > cases. The only real use case I could imagine is a daemon handling >> > bluetooth requests with user input needed. But that is not for the >> > platform to provide. Products should provide that system dialog >> > component and register it through the Agent interface. >> > >> > Of course we could do a reference implementation, but it would be >> > example code rather than a deployed component. >> > >> > > So it is not necessary for all the services to call BlueZ through >> > > CAPI, especially >> > for the upstream projects already call BlueZ directly, we need not >> > to make it call through CAPI. And we can assume that that project >> > maintainer will maintain the project to align with BlueZ. Like >> > oFono, it will call to BlueZ direct for HFP support. >> > > >> > > On the contrary, Samsung want their telephony stack talk to BlueZ >> > > through >> > CAPI, so they want to keep the HFP CAPI. >> > >> > OK, so this is only Samsung-specific. Does that affect Tizen mobile >> > only? Any other needs there? (since HFP CAPI doesn't need a >> > daemon) >> > >> > > So in general, the Tizen specific apps or services should based >> > > on CAPI, some >> > system level service(especially upstream one) should case by case. >> > >> > C API perhaps, but why another service? A minimal solution would be >> > a library which is an extension/wrapper of bluez lib, also >> > implementing the CAPI, and provide the agent as a testable example >> > code, similar to >> > http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/simple-age >> > n t but in C. Tizen products could extend that for implementing the >> > device specific dialog. >> > >> > Best regards, >> > Zoltan >> > _______________________________________________ >> > Dev mailing list >> > [email protected] >> > https://lists.tizen.org/listinfo/dev >> -------------------------------------------------------------- >> Intel Shannon Limited >> Registered in Ireland >> Registered Office: Collinstown Industrial Park, Leixlip, County >> Kildare Registered Number: 308263 Business address: Dromore House, >> East Park, Shannon, Co. Clare >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County > Kildare Registered Number: 308263 Business address: Dromore House, > East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
