All of lore.kernel.org
 help / color / mirror / Atom feed
From: =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont <remi@remlab.net>
To: ofono@ofono.org
Subject: Re: GPRS support for Ofono
Date: Wed, 02 Sep 2009 18:38:29 +0300	[thread overview]
Message-ID: <200909021838.29834.remi@remlab.net> (raw)
In-Reply-To: <200909021000.23069.denkenz@gmail.com>

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

Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit :
> Actually this one is missing from the API proposal.  Marcel already wanted
> the context type (internet, mms, wap, etc) information.  I've updated the
> proposed API in git.

This is not going to work.

Depending on the operator, you may have more than one "type" for a single 
context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. 
Internet with only Web and Internet with full IP).

> As discussed previously, we want oFono to manage this data, since it can do
> this by using the IMSI.  So if you insert a different operator SIM your APN
> settings are magically updated for that operator.

I have a feeling this does not work either. If I upgrade my subscription, the 
APN may change while not the IMSI, no?

> > In my proposal the "Status" variable was a three-state variable,
> > having the states "attached", "detached" and "suspended". "Suspended"
> > was specified to mean that the GPRS was attached, but temporarily not
> > available (for instance because of a 2G phone call or temporary loss
> > of cellular connectivity). In the IRC discussion someone said that
> > this property would not be part of Denis's API because the tri-state
> > variables were bad and the "suspended" status was not supported by
>
> So the general rule is that if a feature isn't explicitly allowed in
> 27.007, we do not support it.  There are exceptions to this of course. 
> 27.007 only supports two states for context: activated and deactivated.

Our general rule is that if we have a UI requirement, or better an actual use 
case for it, we support it. Suspended GPRS fits both.

> > spec 27.007. However, the problem is that Maemo 5 already has UI
> > support for indicating that the connection is suspended, and that
> > makes it harder to drop the feature. Could the "suspended" status enum
> > still be left there, and just have the modems that don't support the
> > feature to never go to "suspended" mode?
>
> I'd rather not.
>
> If this feature is really required, then some sort of heuristic can be
> applied.  (e.g. Powered on, Attached on, but context is deactivated most
> likely means temporary unavailability of resources)

Is this some kind of joke? Don't you know the difference between pause and 
stop on your MP3 player and between suspend to memory and power off on your 
computer?

Second guessing does not fit in my definition of "easy to use self-
documenting" for an API.

> This really belong in the kernel.  Only the kernel can reliably know when a
> network interface has been brought down and notify the interested
> applications with the statistics.

You're missing the point.

Yes, any body can extract the statistics for a running context. But data 
counters are cumulating. To compute the sum properly, there are but two 
options:
# Either the GPRS middleware requests kernel per-interface statistics right 
before destroying the interface, and sums with the earlier total.
# Or the modem does it internally.

There is no way some random userland interface application can do it just by 
requesting the kernel, since it cannot know when to request those statistics.

> Nokia hardware supports this explicitly, but many others don't.

That's irrelevant. Hardware support helps in the sense that it can include 
statistics for contexts external to Ofono. If the hardware does not support 
it, then it needs to be done manually in the GPRS middleware.

That won't make the requirement go away.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

  parent reply	other threads:[~2009-09-02 15:38 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01 11:09 GPRS support for Ofono Ismo Puustinen
2009-09-01 19:02 ` Jean-Christian de Rivaz
2009-09-01 19:25   ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-01 20:17     ` Jean-Christian de Rivaz
2009-09-01 20:26       ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-01 20:30       ` Christensen, Mikkel
2009-09-01 19:27   ` Christensen, Mikkel
2009-09-01 21:36 ` Denis Kenzior
2009-09-01 22:42   ` Marcel Holtmann
2009-09-01 22:50     ` Denis Kenzior
2009-09-02  6:39     ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02  9:16       ` Marcel Holtmann
2009-09-02  9:22         ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02 10:43           ` Aki Niemi
2009-09-02 11:03             ` Marcel Holtmann
2009-09-02 11:19               ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02 11:30   ` Ismo Puustinen
2009-09-02 12:02     ` Marcel Holtmann
2009-09-02 12:34       ` Aki Niemi
2009-09-02 12:46         ` Marcel Holtmann
2009-09-02 12:51           ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02 15:28         ` Denis Kenzior
2009-09-02 15:42           ` Aki Niemi
2009-09-02 20:37             ` Marcel Holtmann
2009-09-02 20:36               ` Denis Kenzior
2009-09-02 21:09                 ` Marcel Holtmann
2009-09-02 12:46       ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02 13:01         ` Marcel Holtmann
2009-09-02 17:51           ` Bastian, Waldo
2009-09-02 20:40             ` Marcel Holtmann
2009-09-02 15:00     ` Denis Kenzior
2009-09-02 15:32       ` Aki Niemi
2009-09-02 15:36         ` Denis Kenzior
2009-09-02 15:38       ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont [this message]
2009-09-02 16:26         ` Denis Kenzior
2009-09-02 17:39           ` Bastian, Waldo
2009-09-02 17:46             ` Denis Kenzior
2009-09-02 18:41               ` Bastian, Waldo
2009-09-02 21:01                 ` Marcel Holtmann
2009-09-02 21:10                   ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-09-02 21:18                     ` Marcel Holtmann
2009-09-02 20:53         ` Marcel Holtmann

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=200909021838.29834.remi@remlab.net \
    --to=remi@remlab.net \
    --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.