All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: RFC: API for Neighbouring Cell Info
Date: Fri, 29 Jan 2010 09:56:59 -0600	[thread overview]
Message-ID: <201001290957.00346.denkenz@gmail.com> (raw)
In-Reply-To: <1264752250.19283.773.camel@phoenix.elisa-laajakaista.fi>

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

Hi Aki,

> > Your feedback is highly appreciated, especially from those who plan to
> > use this information for location purposes.
> 
> I think the pattern you use here is wrong. This needs to be a method
> call; a signal won't work. The measurement data is constantly changing,
> and you don't want a constant stream of PropertyChanged() signals.
> 
> So I think something like this instead:
> 
> GetNeighborCells() -> a{sv}, aa{sv}

How is this information obtained from the modem? Is the modem polled? Does it 
signal this data as it changes?  Honestly I don't like either approach, the 
Agent pattern would be a much better fit here.  This would allow us to specify 
the polling/update interval and stop neighbor cell updates when no one is 
interested in them.

> > Once there is agreement on the API we can discuss whether it makes
> > sense to add some skeleton support in the oFono core or leave it to
> > each individual modem plugin to implement the DBUS service in its
> > entire.
> 
> I think it's reasonable to assume that most modems support this. There
> is a standard to follow, and at least isimodem will have a driver for
> it. So I would make it a proper atom from the beginning.

I'd like to see the low level driver API proposal first.  The Nokia isimodem 
interface is actually quite sane, AT command modems are usually not so...  If 
we make this into a proper atom we have to make this work for all hardware 
from the beginning.

> Other comments on the interface:
> > Properties boolean Enabled [readwrite]
> >
> > 			Boolean representing whether the interface provides
> > 			neighbouring cell information.
> 
> This is useless. If a modem driver doesn't support neighbor cell info,
> it won't registered a driver and the interface just doesn't show up.

Being able to turn this capability off is useful.  If there are no consumers, 
then these types of notifications should be turned off to save power / wakeups.

Regards,
-Denis

  reply	other threads:[~2010-01-29 15:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-28 18:03 RFC: API for Neighbouring Cell Info Bastian, Waldo
2010-01-29  8:04 ` Aki Niemi
2010-01-29 15:56   ` Denis Kenzior [this message]
2010-01-29 16:29     ` Aki Niemi
2010-01-29 16:51       ` Denis Kenzior
2010-01-29 21:14         ` Bastian, Waldo
2010-01-29 21:31           ` Denis Kenzior
2010-01-31 11:11       ` Jussi Kukkonen
2010-01-31 16:04         ` Marcel Holtmann
2010-01-29 21:04   ` Bastian, Waldo

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=201001290957.00346.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.