[Dev] FW: Tizen 3 services: use case for multi user
wu.zheng at intel.com
Mon Sep 22 02:40:33 GMT 2014
We still want to clear the Multiuser requirement for NTB.
Can you share the Multiuser requirement for NTB?
Such as multi-paring, multi-adapter and so on.
At current, NTB run on app mode not root mode, so we need to design the related solution depend on it.
1. For multi-paring, can you share your idea for Luiz's and martin's comment.
(in the following mail)
2. For adapter multi-control, we want to use a lock to implement it.
(userA and userB)
once userA uses bluetooth, he set a lock on the adapter and userB can't use bluetooth.
After userA uses bluetooth, he will unlock it and userB can use bluetooth.
We will use the solution to implement adapter multi-control.
(Please check the following mail too).
>From: Xu, Martin
>Sent: Wednesday, September 10, 2014 3:30 AM
>To: Von Dentz, Luiz; Ohly, Patrick
>Cc: dev at lists.tizen.org; Zheng, Wu
>Subject: RE: [Dev] Tizen 3 services: use case for multi user
>> -----Original Message-----
>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Von Dentz,
>> Sent: Friday, September 05, 2014 1:01
>> To: Ohly, Patrick
>> Cc: dev at lists.tizen.org
>> Subject: Re: [Dev] Tizen 3 services: use case for multi user
>> Hi Patrick,
>> 'UserA requests to pair with DeviceR
>> an authentication popup appears on UserA default screen (from DeviceL)
>> and DeviceR allowing pairing UserB requests to pair with Device an
>> authentication popup appears on UserB default screen (from DeviceL)
>> and DeviceR allowing pairing UserA and UserB are paired with DeviceR'
>I agree with Luiz's comments, the paring is based on device not user for
>And I think the reason why we want to support multi-paring is just to protect the
>personal date for PBAP, MAP and so on, which is our second request.
>However, PBAP, MAP, FTP, OPP are all based on OBexd, and run at normal user
>privilege not root, and each has it's own default home directory bound with the
>user to share the data through Bluetooth.
>So that means for above profiles, the multi-user are supported natively.
>We just did not try and verify the scenario before, but I think it will not big issue
>here, we will have a try on it.
>So as to adapter multi-control, I think that requirement is reasonable. We can
>try to add a lock to each adapter at NTB, so normal user needs to acquire the
>lock before accessing it,(release the lock after the adapter is not be used
>anymore), that will not break current framework in NTB and BlueZ and
>implement the features.
More information about the Dev