> Here a proposal for call counters implementation for keeping
> of the total incoming and outgoing call duration counters. Each
> established call instance is contributing to either of the call
> duration counters. The 2 counters are updated periodically when
> there is an established call and the information is stored in
> a file. The bookkeeping of the call duration counters are per IMSI
> The implementation makes use of the history framework which had to be
> expanded with a function for marking the beginning of a voice call.
> There is a D-Bus interface to call counters for reading and clearing
> the counters.
This set looks good to me, and I believe you fixed the issues from
previous review comments. Denis, are you ok with this?
so Denis and I talked about this a little bit and I am not fine with
this at all.
Lets take this one step and please explain to me what your requirements
and objectives are. I also wanna see a top to bottom from UI down to the
modem usage of this API.
My main concerns are here that we are waking up ofonod every 10 seconds
and consuming heavy IO with writing this information to disk. In
addition to that there is no clear UI usage for the getter API.
What are the granularity there. What is the expected user experience
with this API. I don't see any clear usage model here.
In addition to that, what is the problem with just updating the stats
after the call has ended?
Are you really expecting realtime updates of call time stats for some
hidden UI stats menu? This would be a really expensive change for just
Has anybody looked at how we are doing realtime stats inside ConnMan?