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
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
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
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
My vote would be in favor of the first option, for the sake of
What do you think? Any other alternative?
Nope, your proposal is in line with my current thinking.