support for call history sync

[zolkis]

Requirement: a phone call should always be recorded in call history. Even if the system load is so high that an incoming call is not shown until timeout, the call should be recorded as a missed call (real use case, with measurements and proof).

There are 2 ways to mitigate:

1. ensure prioritization of the whole SW stack (related processes) up to the dialer/web runtime.
2. ensure prioritization of a small core component in telephony MW which keeps a short log of call history, which is then synchronized with the dialer app(s). Here we have 2 cases: a. After sync, the short log is cleared, i.e only one entity can read it. b. A full call history DB is maintained, with a client API to read, write back, revisions support, id allocation. This added complexity works against the requirement, so it is not desirable. 2a is the simpler, preferred solution.

If option 1 is feasible, then we don't need any action. If option 2 is chosen in a platform (like in our case, 2a), then we need an API for call history sync. The impact is to move call history to the main spec (not appendix), and define a sync API to fetch call history.

Possible conflicting requirements of call history across different platforms:

1. different dialer apps should see the same call history
2. different dialer apps should maintain their own slice of call history.

In the first case, a common call history storage is needed, but then that could be provided by the telephony middleware or the API implementation (2b), and a sync API could be used to sync that data into the app cache, and back. Sync API functionality needs to cover:

• read call history items since last read (app specific)
• write call history items since last write (app specific).
• id's have to be allocated from a central place, in order to ensure uniqueness.

In the second case, dialers are not required to see the same call history, so it is OK if either one reads the short log via a DataStore API, and no need to sync back.

In both cases it seems feasible to use DataStore API for sync, with the schema of CallHistoryEntry. We need to have a way to say from the dialer that "I am using a DataStore with schema specified by CallHistoryEntry", similar to the C++ syntax of:

DataStore<CallHistoryEntry> callHistory;

Discussion time :).

[hsinyi]

I am not sure I am following the whole issue. So, first of all I want to figure out the scenario: 1) Are we considering the case that more than one dialer app could be active at the same time? 2) Which of the followingsis the requirement this API would like to support?

1. different dialer apps should see the same call history
2. different dialer apps should maintain their own slice of call history.

Quote from Zoltan: Here we have 2 cases: a. After sync, the short log is cleared, i.e only one entity can read it. b. A full call history DB is maintained, with a client API to read, write back, revisions support, id allocation. This added complexity works against the requirement, so it is not desirable. 2a is the simpler, preferred solution.

my question to a): how to determine which app is that only one entity? Does a) mean different dialer apps see the different call history?

Quote from Zoltan: In both cases it seems feasible to use DataStore API for sync, with the schema of CallHistoryEntry. We need to have a way to say from the dialer that "I am using a DataStore with schema specified by CallHistoryEntry", similar to the C++ syntax of: DataStore callHistory;

Wouldn't that be something like "navigator.getDataStores("callhsitory")"? [1]

Thanks!

[1] https://wiki.mozilla.org/WebAPI/DataStore

[zolkis]

@hsinyi

"1) Are we considering the case that more than 
one dialer app could be active at the same time?"

Yes, there could be more dialers, handling different or overlapping telephony services (app choice). Call history could be maintained per service or combined (platform /app choice). Also, call history could be in system-level and app-level storage. There may be only one dialer allowed to a given telephony service (platform choice, then user choice on which one is it). That is a platform, or user choice.

"my question to a): how to determine which app is that only one entity? "

The user selects it.

"Does a) mean different dialer apps see the different call history? "

Yes. In that particular choice of implementation, yes.

The question is what is our assumption on this.Similar to what we have agreed in Messaging 2 hours ago, the current assumption could be that we have a system level storage for call history, and each app may maintain their own cache, too. In this scenario, marking e.g. a missed call as "seen" will have effect on all dialers, since their call history cache will be synchronized with the system storage.

But do we need the app cache at all? The main queries on call history are very simple: get all past calls, and have events for updates. Then, the app can show them in different lists: missed, dialed, received, etc, or in one list.

So I don't see why apps would want to index call history: they are just interested to get all the data. Therefore a DataStore like API is good enough, and it will use only a subset of it. Should we define a callhistory specific wrapper for storage interface?

"Wouldn't that be something like "navigator.getDataStores("callhsitory")"? [1]"

OK, that is good enough, assuming there in one common schema for CallHistory, which is our case.