> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Dominig ar Foll > (Intel OTC) > Sent: Friday, September 5, 2014 9:53 AM > To: [email protected] > Subject: Re: [Dev] Tizen 3 services: use case for multi user > > > > I think each seat should have it's own BT adapter named appropriately, > > and then each user can pair devices on their own seat and the pairing > > data is stored in user's home directory. > > > > Seat tagging based on USB device trees works already just fine. > IVI Head unit will not have as many adaptor than we have people in the car.
I would agree with Dominique on this supposition. > Furthermore the requirement from Genivi is that a user application can be > moved from one seat to an other without disconnection, so the binding > between a seat an a user does not exist. > We need to share BT adaptor between users which is why we need a BT > framework on top of BlueZ to manage those issues. In a shared adaptor model, with multiple potential users, how is it expected Murphy, the policy engine, interacts? You may want to consider that a product may wish to employ policy on top of functionality - i.e. just because you can practically allow 4 devices to pair, you might not want to allow this because it doesn't match your UI behavior expectations? Having hooks to control this may be useful....? Then to the concrete example of contact sync. Perhaps the thought process should expand beyond muti-user vis-à-vis devices and encompass how to handle/manage the data and the type of data? I could think of some scenarios where I would have a userA wanting to pair (own) UserB's device. If you sit the contacts into the user home dir, you could end up with a duplication of the contact db on the system - No? Second angle to consider here is this. If I've enough access to the vehicle, the likely hood is I'm in the same social circle as others who also share that vehicle. Ergo a high probability that two users overlap on contacts. That observation could also expand to the corporate car market, where the social circle is the enterprise address book. It may break down for the shared car or rental sector. With a per user storage solution, you have challenges in optimizing for storage - why store and identical contact in 2 locations? Why store 2 identical albums on the device? It may seem like unnecessary complication, but consider knock on impact to eMMC wearout issues and 15year lifetime expectations in the auto sector. Would it be worth considering, from a device perspective it knows only of its MAC address and a PIN to auth. PIN is loosely coupled to the user, but from a BT spec perspective, the protocol has no real concept of the user. Then following this, could it make sense that you store the contacts in some [whateverpath/BTMACADDR]? Or have a central storage location and tag the contact to the btaddr - identify duplicates and augment the association with the additional btaddr? Then layer user meta data above this. At the end of the day, some OEMs (IVI) may view it a feature that it has 1 system contact address book, it may choose to a) segregate this so the contacts are viewed per device or b) harmonize the address book into 1 list (perhaps filtering out duplicates - after all if you are willing to share a ride with someone, you probably know the same people too). I could also foresee that it reasonable that when sitting with my partner, I want to use my device to make a call to a contact stored in her addressbook. Finally, having a device orientated store structure could offer some advantage to purging data - for rental cars, I may want to have a generic 'guest' (or even have a pay-per service model where when renting, could 'upgrade' guest to enable navigation for a fee), so I may want to invoke the user concept to bucket different services, but I need a way to legally adhere to the data protection act by purging the addressbook without having to delete /recreate the user profile - less erase/rewrites helps my flash memory longevity - which is a far bigger issue for IVI than multiuser, as the typical head unit replacement cost - parts and labor - could reach $3000. > > Dominig > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare 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
