This seem to refer to the mobile stack. In IVI, at least the following are not correct: - Messaging is not based on email-service and msg-service. It is/will be based on an extension using BlueZ DBUS API's for handling bluetooth MAP sessions (supporting SMS, MMS and email). - Call History is not based on contacts-service. It is/will be based on an extension using BlueZ DBUS API's for handling bluetooth PBAP sessions, and optionally ofono call history DBUS interface (in case of the presence of a local modem). [- Contacts is not based on contacts-server either]. It will be based on the same BT grounds as Call History + EDS. [- Telephony is missing, it is based on ofono/phoned DBUS interfaces and Contacts API]
Best regards, Zoltan On Wed, May 14, 2014 at 6:21 PM, Dominig ar Foll (Intel OTC) <[email protected]> wrote: > Hello; > > in the discussion about enforcing application manifest which are currently > going now, I would like to help people to understand that D-Bus is not the > only transport mechanism in play. > In the file pointed by the follpwing link you will find an analysis of how > the legacy WRT is implemented. > It list for main WebAPI which CAPI are called and when transport is > activated by the CAPI. > > You will see quickly that we need a solution that works with other transport > than D-BUS. > > Enjoy the reading. > https://docs.google.com/a/fridu.net/spreadsheet/ccc?key=0ArDphLgC1YYXdEU4M3BRdWlyZUNyWncxeFBXeERNTmc&usp=drive_web#gid=2 > > -- > Dominig ar Foll > Senior Software Architect > Open Source Technology Centre > Intel SSG > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
