On Wed, Jul 2, 2014 at 5:39 PM, José Bollo <[email protected]> wrote: > 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. >
Well, the push is understood. But defining a single C API which matches well both the current mobile and IVI API's and it's wide and deep enough to implement each profile's use cases is not at all easy. All previous similar efforts that I've seen in the past decade kind of failed so far, so the odds are against it, therefore more care and deeper consideration needs to be taken than what's visible now. Especially when it's not clear how SAPI will deal with notifications (callbacks?), dynamic interfaces that can appear and disappear (common in telephony), which can be discovered, etc., how exactly the separation of signaling and user data transfer will work (together with marshaling), how much of hardcoded latency we introduce in different use cases, how does it scale with the use cases, etc. It would be so much easier and better to enable using DBUS safely from the applications, and for non-DBUS interfaces implement the SAPI. That design needs to be done per domain, involving the relevant stakeholders from each domain and Tizen profile. It's not enough if one team, however competent and enthusiastic, defines what they think should be enough based on past work or some existing interfaces, to tick the SAPI checkbox: the criterion is that we need to be able to implement our use cases with the SAPI in a secure way. The best way for that is if the SAPI is close to an already (or partially) standardized API (e.g. W3C) or tried-and-tested upstream API design (e.g. oFono/BlueZ DBUS). For any case, first we need to gather these use cases, determine test data sets, latency requirements etc. There may be such effort, just that it's not visible. I could help with, and expect to be in the loop for the SAPI design of Messaging/Cellular, Telephony+Call History, and also Contacts domains, including related Bluetooth profiles. But as said, I would recommend making DBUS safely usable from apps, as this would suddenly solve all the above. Then it is still possible to define a SAPI for those who don't want to use DBUS. But when DBUS is there, please make it possible to use it and please don't make it a policy to hide it. It's well worth the price we'd pay in extra maintenance of modified dbus-daemon etc. Best regards, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
