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
next prev parent 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.