I am interested in taking part in this, actually I've already been working in this area, keeping this possibility of solution in mind. Also, Patrick has had clear ideas wrt contacts management.
In general, the advantages of a 'headless dialer' service are: - one integration point for native and web apps, with permissions/security enforcement - common data integration point, per user (call history, messages and contacts), over persistent/local sources (built-in modem, SIM) and transient/remote sources (bluetooth paired devices through HFP, PBAP, MAP, or web services) - audio management integration point; we can offload the app from most of that; however, there are possible exceptions here, for instance an app wants to delay incoming call audio notification until the visual notification appears for 2-3 seconds; so it needs to be able to control notifications itself. - latency optimization opportunity. The points against a 'headless dialer' idea are: - there are technologies where even the UX is part of the protocol, for instance in CDMA call waiting and 3-way call handling (will return to this later) - disputable if it can be generic enough, builds in some inflexibility anyway - the data integration works against latency and performance. It would give more opportunity to create a higher priority vertical process group for handling incoming call latency, if there would be less dependencies to load. Feel free to extend both pro's and con's. There is existing code for most of this. The overhead of experimenting with a new daemon + CAPI seems minimal to me, compared to the achievable benefits. After performance measurements we can still decide this is not optimal or acceptable, and do the necessary changes. Nevertheless we will never know without doing it. *** API issues. When it comes to the W3C SysApps specs of Telephony, Messaging and Contacts, note that these are still changing, with some of them having undefined future. As a matter of fact I am working with some SysApps members (Mozilla, Qualcomm) on a new shot of Telephony API, based on the implementation experiences so far on Android/Firefox OS, and Crosswalk/oFono/Tizen IVI. So at this point some of the API's are not stable yet, since until recently we didn't have the requirement to be compatible with PBAP, MAP and HFP. Notably, the problem always is with the data management part, in the past and in the present, industry-wide. Therefore I would separate the functional interfaces (e.g. making call, sending SMS etc) from data management (call history/message/contacts store listing, search etc) into separate API's. Instead of generic data API, there I would only do sync from a given source (local address book, SIM, PBAP/MAP etc), which belongs to the functional interface. Compliance should concern only the functional API's, and leave data management to the apps. They will know better what data models do they want to use. Today's apps like to manage this instead of rigidly imposed data models. This both makes the platform simpler and the apps more versatile, at the expense of bigger apps (which is the current tendency anyway). When designing a middleware CAPI, we can draw experiences both from the W3C work and the existing standards mentioned above. We can make a separate Intents-like API, but I see it orthogonal to the functional CAPI since it's higher level and with more restricted and better defined use cases. I suggest designing a new set of experimental API's, and keeping the old Tizen API's along to stay compatible. Also define an API deprecation roadmap; the decision of promoting/demoting API's belongs to the TSG. *** Implementation notes. After the skeleton for this project (daemon+capi lib) is created, integrating into Tizen/security/permission handling etc, we can move existing relevant functional code from Crosswalk native extensions, and SyncEvolution into the new service, implement the CAPI, and also modify the extensions to use the new CAPI. What IPC should we use for the CAPI? *** Documentation As mentioned, the W3C specifications are rather input documents than documentation. Much of this has already been discussed, we need to summarize it in one place. Best regards, Zoltan On Mon, Nov 24, 2014 at 5:15 PM, Dominig ar Foll <[email protected]> wrote: > Hello, > > I would like to open a discussion on what should be Tizen 3 unified > strategy for Telephony management in Tizen 3. With integration in Tizen > 3 of a Mobile profile just been started, I thought that the issue is > ripe enough to be discussed. > > In Telephony I would like to en-globe : > - voice call > - SMS/MMS > - Contact > > 1) Need > ----------- > It should be possible to allow an App (HMTL5/Native) to : > - offer to the user to make a phone call > - offer the user to start a phone with a pre-entered number/contact > - accept / reject an incoming call > - send receive SMS/MMS (without or with out attachments) > > Obviously when using call or message services , the events related to > these serives should be registered in the standard history data base in > a same way as when created with the default platform applications. > > We should also be able to select the target device/firmware in charge of > serving such communication request (Internal Model, Phone via Tethering, > VoIP : eg Skype) > > 2) Architecture option > ------------------------------ > It is very unlikely that we will get the same low level middleware on > all platforms and I do not believe that we can assume a unification at > that level. That imply the creation of a set of unified APIs which can > connect on different low level middlewares. > > The easy model would be to copy Android model where, an application > willing to use a Com function (message, voice or contact) simply call an > application in charge of handling the service. Alternative is to create > a set of APIs which can be used by the App to initiate the Communication. > > The first model is far simpler and close to most Phone OS current mode > of operation. > It does present the main advantage of easing the coordination between > Apps and platform base software but does not make that easy the > provision of compliant W3C phone API which tend to work at lower level. > http://www.w3.org/2012/sysapps/telephony/ > > The provision of a Dailer and a message handler with an enable remote > control mode could be a valid option to serve both needs. > Obviously that Dialer would have to be headless (no default UI) in order > to let any platform to build their preferred solution adpated to their need. > > 3) How to move from here > ------------------------------------ > We have a well defined W3C API for Telephone and Message. Could we agree > to use that as our base for a remote control of a Dialer ? > > We must have somewhere a set a CAPI for managing a dailer, message and > contact hander in Tizen 2.3. Would that be a valid base for a dialer ? > - can it be made headless ? > - does it cover all requirements ? > - do we have a documentation available somewhere in the Wiki ? > > Thanks in advance to help me to progress toward a unified solution. > > > -- > Dominig ar Foll > Senior Software Architect > Intel Open Source Technology Centre > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
