[Dev] New Tizen Bluetooth Framwork (NTB) wiki page
zoltan.kis at intel.com
Mon May 12 14:35:57 GMT 2014
On Mon, May 12, 2014 at 3:43 PM, Le Foll - Intel, Dominique
<dominique.le.foll at intel.com> 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?
> 2014-05-05 16:55 GMT+02:00 Kis, Zoltan <zoltan.kis at intel.com>:
>> On Fri, May 2, 2014 at 12:25 AM, Xu, Martin <martin.xu at intel.com> wrote:
>> > We have created the wiki page for NTB.
>> > https://wiki.tizen.org/wiki/NTB_Architecture
>> 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
>> - For developers, what makes it worth learning to use a wrapper API,
>> and having one extra DBUS hop compared to direct access?
>> Best regards,
>> Dev mailing list
>> Dev at lists.tizen.org
> 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.
More information about the Dev