All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: [PATCH 0/5] Call Counters (2nd)
Date: Wed, 08 Dec 2010 13:41:32 +0100	[thread overview]
Message-ID: <1291812092.4795.165.camel@aeonflux> (raw)
In-Reply-To: <AANLkTinYryk1jdhdVRXh1RXn5CvwrD_A8y2GPBcP0ZsK@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

Hi Aki,

> > so Denis and I talked about this a little bit and I am not fine with
> > this at all.
> 
> Next time, can you invite me to join your little talk?

because you are not sitting next to me right now ;)

> > 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.
> 
> We need a UI showing total MO and MT call times. They also need to be
> able to be reset, if the user so wishes. The data needs to be
> reasonably reliable.

Fair enough, but when I look at such a feature as a whole, then my
question is when does it need to be shown? What is your user interaction
requirement with this data?

Andras, please explain what reasonable reliable means.

> > 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 do you mean? Do you mean your iPhone has no such UI?

I have actually tested this with an iPhone and it has such an UI
element, but it is not realtime. It gets updated after the call has been
completed.

So why can't we just update/reset this in Tracker via the history plugin
in a general way. I am failing to see the need for this inside oFono. It
seems to me that doing this within the scope of the Tracker integration
is a lot cleaner and better for CPU and IO usage.

> The reason these are not properties is just because it makes no sense
> to update the counters "live". The UI can poll if it so wishes, but
> the poll interval is not something we want to decide.
> 
> > 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?
> 
> Because if your battery runs out in the middle of a 4 hour conference
> call, your timers are not updated and become worthless. Obviously,
> this is a compromise between how reliable the counters are and how
> many wakeups and IO we can bear.

I think this is not a good idea to have oFono handles this. Why can't
the system daemon just shutdown all calls when the battery reaches
critical limit.

You will never fully run down the battery anyway. One of the system
health components in the system will prevent it and then can cleanly
shutdown oFono and thus all calls. The only case where the system could
potentially misfunction in this area would be an emergency call. But
that is a total different use case anyway.

Regards

Marcel



  reply	other threads:[~2010-12-08 12:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 16:25 [PATCH 0/5] Call Counters (2nd) Andras Domokos
2010-11-22 16:25 ` [RFC PATCH 1/5] history: expand history API include file Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 2/5] history: expand history API Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 3/5] voicecall: take into use the new history function Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 4/5] plugins: add call counters Andras Domokos
2010-11-22 16:26 ` [RFC PATCH 5/5] doc: call counters API doc Andras Domokos
2010-12-07 12:57 ` [PATCH 0/5] Call Counters (2nd) Aki Niemi
2010-12-07 18:33   ` Denis Kenzior
2010-12-08  9:03   ` Marcel Holtmann
2010-12-08  9:34     ` Aki Niemi
2010-12-08 12:41       ` Marcel Holtmann [this message]
2010-12-08 13:28         ` Mika.Liljeberg
2010-12-08 16:01         ` Andras Domokos
2010-12-08 16:12           ` Marcel Holtmann
2010-12-08 17:30             ` Andras Domokos
2010-12-08 22:32               ` Marcel Holtmann
2010-12-08 21:02             ` Kai.Vehmanen
2010-12-08 22:35               ` Marcel Holtmann
2010-12-09 12:25                 ` Kai.Vehmanen
2010-12-09 18:10                   ` Marcel Holtmann
2010-12-09 19:52                     ` Kai.Vehmanen
2010-12-09 22:53                       ` Marcel Holtmann
2010-12-10  8:14                         ` Andras Domokos
2010-12-10 17:57                         ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2010-12-10 18:34                           ` Marcel Holtmann
2010-12-10 23:57                             ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2010-12-11 14:57                               ` Marcel Holtmann
2010-12-13  7:56                               ` Kai.Vehmanen
2010-12-12 15:46                         ` Kai.Vehmanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1291812092.4795.165.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.