On mer, 2014-07-02 at 16:26 +0300, Kis, Zoltan wrote: > On Wed, Jul 2, 2014 at 3:18 PM, José Bollo > <[email protected]> wrote: > > On mer, 2014-07-02 at 09:08 +0200, Patrick Ohly wrote: > > > > (snip) > > > > > >> The capi for email doesn't allow fetching, the email-service does. So we > >> need to clarify first which one is supposed to be wrapped. > >> > > > > I raised the same conclusion after studying the implementation of WRT in > > tizen 2. Here is the place where I put elements of this study: > > > > https://wiki.tizen.org/wiki/Security/Privileges_Study_For_Tizen3#Reconstruction_of_dependencies_of_modules_of_wrt-plugins-tizen > > > > As you can see there, the "Messaging" module uses the services of > > platform/core/messaging/email-service and of > > platform/core/messaging/msg-service. None of it are part of the core > > API. > > > > These services are (from the client side) accessing a server through > > sockets/IPC. No DBUS. > > This is not valid for Tizen IVI, only for mobile. > In IVI, > - Messaging and Email domain uses MAP Bluetooth profile to access > messaging data. Through DBUS. > - the telephony domain uses oFono DBUS API's and HFP+PBAP Bluetooth profiles. > - the contacts domain uses PBAP Bluetooth profile to access data, through > DBUS. > They are NOT using the dependencies listed in the wiki pages. > Please update everywhere, unless you want to build a SAPI on false > assumptions.
Hi Zoltan, Thank you for the information. I suppose I had to know it already! But .... The wiki page that I made is based on Tizen 2 that is important for mobile, wearable and TV. The problem is, from the beginning, an architectural problem. What part of tizen have to be changed to implement any profile? From what I'm understanding there is an important benefit to use a common native and secure API. The first benefit is that crosswalk's tizen extensions are immutable across profiles. But other native tools can gaint the same benefit. The second benefit is that the common tools would be independent of the technology used: UDS, DBUS, KDUS, ... An other name of SAPI is Service API what means that it is the common API for services. Any comments are welcome because it is an important topic. I think that I will update soon the SAPI page on the wiki to reflect the various discussions having taken place here so it's time to react. Best regards José > > Best regards, > Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
