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

Kis, Zoltan zoltan.kis at intel.com
Mon May 12 14:35:57 GMT 2014


Hi Dominique,

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?

Best regards,
Zoltan


> 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
>> >
>>
>> 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
>> Dev at lists.tizen.org
>> 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.


More information about the Dev mailing list