From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: Bluetooth HF role
Date: Thu, 01 Sep 2011 03:18:00 -0500 [thread overview]
Message-ID: <4E5F3FB8.5030505@gmail.com> (raw)
In-Reply-To: <4E687C55.5030807@bmw-carit.de>
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
Hi Mikel,
>
> Before discussing the source code itself, I would like to know your
> opinion about the different alternatives that come into my mind.
>
> When you talk about a new atom interface, we could:
>
> a. Create an HFP interface that includes all bluetooth-specific
> extensions. This could something like org.ofono.Handsfree or
> org.ofono.HfpModem.
This is my preferred option.
> b. Be more consistent with the existing oFono API and split the new
> extensions into several interfaces, such as org.ofono.hfp.Modem and
> org.ofono.hfp.VoiceCallManager (and whatever else is needed). This
> second interface would support methods such as Redial() and
> AnswerAndHold().
I don't think this is a good idea, you lose much of the flexibility for
the applications; e.g. being able to implement the same API and work on
real modems, hfp devices, sap devices, etc.
Having said that, the +BTRH is a bit special. I believe it is only
supported on CDMA networks, while the HFP protocol is modeled after the
GSM call model. We might have to look into implementing it on
VoiceCallManager and tweak the GSM call state logic accordingly, which
won't be fun ;) Any ideas are welcome here, I have no experience with
Response and Hold or access to networks with it enabled.
> c. If this second approach of hfp.VoiceCallManager is followed, we could
> not only include the extensions there, but also replicate the whole API
> in org.ofono.VoiceCallManager. Personally I would rather not do this,
> but it seems to me that org.ofono.cdma.CdmaVoiceCallManager has been
> designed that way.
>
CDMA versions were designed this way because the CDMA call state machine
is dirt simple. There didn't seem to be a need to make applications
deal with the complexity of the GSM API while having a much simpler
model underneath.
> My vote would be in favor of the first option, for the sake of simplicity.
>
> What do you think? Any other alternative?
Nope, your proposal is in line with my current thinking.
Regards,
-Denis
next prev parent reply other threads:[~2011-09-01 8:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 15:28 Bluetooth HF role Mikel Astiz
2011-08-20 9:00 ` Denis Kenzior
2011-08-25 12:32 ` Mikel Astiz
2011-08-21 2:13 ` Denis Kenzior
2011-09-08 8:27 ` Mikel Astiz
2011-09-01 8:18 ` Denis Kenzior [this message]
2011-09-08 10:03 ` Mikel Astiz
2011-08-24 16:56 ` Gustavo Padovan
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=4E5F3FB8.5030505@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.