[Dev] New Tizen Bluetooth Framwork (NTB) wiki page

Zheng, Wu wu.zheng at intel.com
Tue May 20 02:47:47 GMT 2014


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:kevron.m.rees at intel.com] 
Sent: Tuesday, May 20, 2014 5:35 AM
To: Zheng, Wu
Cc: Counihan, Tom; dev at lists.tizen.org; 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 <wu.zheng at intel.com> 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:dev-bounces at lists.tizen.org] On Behalf Of Counihan, 
> Tom
> Sent: Monday, May 19, 2014 2:59 PM
> To: Counihan, Tom; Kis, Zoltan; Xu, Martin
> Cc: dev at lists.tizen.org; 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:dev-bounces at lists.tizen.org] On Behalf Of Counihan, 
>> Tom
>> Sent: Tuesday, May 13, 2014 11:22 AM
>> To: Kis, Zoltan; Xu, Martin
>> Cc: dev at lists.tizen.org; 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:dev-bounces at lists.tizen.org] On Behalf Of Kis, 
>> > Zoltan
>> > Sent: Wednesday, May 07, 2014 1:57 PM
>> > To: Xu, Martin
>> > Cc: dev at lists.tizen.org; Liu, Bingwei
>> > Subject: Re: [Dev] New Tizen Bluetooth Framwork (NTB) wiki page
>> >
>> > Hello,
>> >
>> > On Mon, May 5, 2014 at 10:00 PM, Xu, Martin <martin.xu at intel.com> 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
>> > Dev at lists.tizen.org
>> > 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
>> Dev at lists.tizen.org
>> 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
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list