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

Kis, Zoltan zoltan.kis at intel.com
Wed May 7 12:57:04 GMT 2014


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
but in C. Tizen products could extend that for implementing the device
specific dialog.

Best regards,

More information about the Dev mailing list