+ zheng Wu
> -----Original Message----- > From: Counihan, Tom > Sent: Tuesday, May 13, 2014 3:22 > 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=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:[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-agent > > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
