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

Xu, Martin martin.xu at intel.com
Tue May 13 18:20:56 GMT 2014


+ zheng Wu

> -----Original Message-----
> From: Counihan, Tom
> Sent: Tuesday, May 13, 2014 3:22
> 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=238193
> PBAP 1.2 -
> https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=281299
> MAP 1.2 -
> https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=274479
> ARVCP 1.5 -
> https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=260861
> 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-agent
> > 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


More information about the Dev mailing list