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

Xu, Martin martin.xu at intel.com
Wed May 7 15:41:34 GMT 2014


Hi:

> -----Original Message-----
> From: Kis, Zoltan [mailto:zoltan.kis at intel.com]
> Sent: Wednesday, May 07, 2014 5:57
> 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.
For Tizen, it is the best solution, and agree to do that at Tizen.

> 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)
At HFP AG, that is Samsung-specific. At IVI, HFP HF, I do not think we need to care about it.

> > 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-agent
> but in C. Tizen products could extend that for implementing the device
> specific dialog.
I hope all the CAPI just wrap of BlueZ lib, that is the right way, but we can't.  



More information about the Dev mailing list