All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: GPRS support for Ofono
Date: Wed, 02 Sep 2009 10:28:52 -0500	[thread overview]
Message-ID: <200909021028.52347.denkenz@gmail.com> (raw)
In-Reply-To: <a32762a20909020534r5d169e36id3ddbb981ca9d187@mail.gmail.com>

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

Hi Aki,

> > We are not going to expose Attach() or Detach() method. As explained
> > there are global anyway and so pointless to expose. This can be handled
> > in the background without bothering the higher level application with
> > these details.
>
> AFAIK, attach status of GPRS has both regulatory aspects to consider
> (some operators require always attached vs. some prohibit it) as well
> as power consumption issues (auto-attach might draw more power than
> on-demand, although there's an inverse effect on latency). These are
> issues you need to take into account, and higher layers in the stack
> definitely *need* to be aware of as well. Also, I don' t think oFono
> is the correct place for these decisions -> better expose a necessary
> API and let upper layers deal with it.

I know you guys are coming from mobile phone perspective, but that one isn't 
the only scenario.  We have netbooks/laptops with gprs data cards to consider 
as well.  Hardcoding operator requirements is also not an option, since SIM 
cards can be changed.

I fundamentally disagree that the logic should be in the higher layers.  oFono 
has all the information to handle this, and can be hinted on what is 
appropriate behavior easily enough.  oFono should simply store the auto-attach 
preferences in its IMSI-indexed preference store.  The operator can bootstrap 
these preferences if required.

>
> In general, I appreciate the attempt to hide ugly details from
> applications, but unfortunately some things can't well be hidden.
> Another unrelated, but similar issue is network scanning. It just
> isn't going to work without us exposing it in the D-Bus API
> explicitly.
>

Modem drivers will have some control over whether the scan is performed 
automatically, but denying the capability for everyone is not the right thing 
to do either.

> The reason is simple, Nokia modems suspend GPRS when scanning (or
> registering), simply because the operation will take roughly three
> times as long with GPRS attached. You will find this feature in
> current phones, too.

Then ideally you should have two scan modes, periodic and user initiated.  For 
periodic mode we don't care how long it takes. 

Regards,
-Denis

  parent reply	other threads:[~2009-09-02 15:28 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 [this message]
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
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=200909021028.52347.denkenz@gmail.com \
    --to=denkenz@gmail.com \
    --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.