Hi Dominique, On Mon, May 12, 2014 at 3:43 PM, Le Foll - Intel, Dominique <[email protected]> wrote: > the issue of using BlueZ directly is linked to the need to enforce the > respect of the Application manifest as well as to respect multi user issues. > It can work in a system where application do not have a manifest which tell > sin details what they can and cannot do.
Based on the wiki, this was not the reason to create NTB :). If this is the reason, it needs to be clearly stated. The use cases are not clearly stated either. Based on the doc alone it looks like this is a pure refactoring exercise of an older component (and actually quite good at that) - but with the new BlueZ 5 interfaces do we really need it? If there are good use cases and architectural reasons, they should be documented in the wiki page. > > look at https://www.tizen.org/privilege/tizen > search for bluetoth in the page. Does that mean for every API involved in the huge list on the page above we intend to create a new wrapping middleware component to add the security checks and other "added value"? If only for a sub-set, then what is that sub-set? That looks like a huge work, more complexity, latency, etc. Or alternatively, could we implement security enforcement in a dbus daemon extension (as suggested before in another thread) and separate the security argument from the API argument? Best regards, Zoltan > 2014-05-05 16:55 GMT+02:00 Kis, Zoltan <[email protected]>: >> >> On Fri, May 2, 2014 at 12:25 AM, Xu, Martin <[email protected]> wrote: >> > We have created the wiki page for NTB. >> > https://wiki.tizen.org/wiki/NTB_Architecture >> > >> >> Hello, >> >> I have some questions for which you likely have answers, but it would >> be good to cover them in the document. >> >> 1) could you list the more elaborate use cases NTB solves and when NTB >> is more useful than direct BlueZ access? If for some use cases one has >> to access directly BlueZ anyway, why could not access BlueZ for >> everything? That would be more consistent for an app developer, and >> wouldn't have to care about possible alignment issues between the >> wrapper and BlueZ. >> >> 2) for MAP and HFP, can NTB really act as a single proxy agent (single >> session) for all apps? to my knowledge, one needs to register the app >> for a session, so AFAIK the proxy NTB model would not work. Has this >> been reviewed by Comms people (Marcel, Luiz, Johan)? >> >> 3) for HFP we prefer handling it not in a bluetooth service daemon, >> but in phoned or dialer, since that allows prioritizing the whole call >> chain separately and with minimal dependencies. >> >> 4.) Other functionality (messaging, contacts etc) may have their own >> reasons to use or not to use NTB, and mostly they can already handle >> BlueZ directly. >> - If you expose the CAPI as a library, what dependencies does it bring? >> - If an app does not use NTB, but uses BlueZ directly, what are the >> consequences? >> - For developers, what makes it worth learning to use a wrapper API, >> and having one extra DBUS hop compared to direct access? >> >> Best regards, >> Zoltan >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev > > > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > 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 [email protected] https://lists.tizen.org/listinfo/dev
