Comments about the proposed new MM D-Bus API

[Aleksander Morgado <aleksander lanedo com>]

Hi Dan & list,

My comments about the proposed new D-Bus API:

1) Regarding frequency/band management:
 * There is now AllowedBands and SupportedBands properties in the API,
but no GetBand() or SetBand(). So really seems the only way to set
specific bands is through writing the AllowedBands property. I don't
think its a good idea, as we really want proper error reporting when
trying to set bands: device may not allow to reset bands while connected
for example, or the specified band mask may not be supported by the
modem. Another option is to silently discard all those possible errors
when trying to set an invalid band configuration in the property... :-/
 * Regarding SupportedBands being a mask. Some devices do support wide
bitmask-like band configurations; but some others just support a closed
list of masks, like: "band1 and band2", "band3 and band4", "band1,
band2, band3 and band4", and maybe they do not support "band1 and band3"
kind of config. But indeed it's very difficult to provide a generic way
of covering all cases, so the bitmask is probably the best approach. For
the cases where specific band masks are supported, we could just perform
a bitwise OR of all supported masks, like:
   "band1 and band2" | \
   "band3 and band4" | \
   "band1, band2, band3 and band4" = "band1, band2, band3 and band4"
And then, let SetBand() really check the passed specific band mask, and
return an error if not allowed (like when passing "band1 and band3" in
the above example.

2) I would definitely remove GetInfo() from the modem API, and leave
manufacturer, model and version/revision as independent read-only
properties set during construction. This was also like that in the
previous API, maybe there's a reason for that that I don't know.

3) I didn't dig much in the CDMA-specific API as I know nothing about
CDMA, so no comments there.

4) In general, given that this is not only a refactor as new things are
being introduced in the API, I would suggest to keep an up-to-date
migration table for all methods and properties, so that it can easily be
checked what was migrated, what was removed and what was newly added.
Once that list of methods/properties is done, we could also use it as a
matrix to identify which features are supported by which plugin (e.g.,
not all plugins support configuring bands). I wouldn't mind to setup
that matrix in some wiki if you agree it's a good idea.

So far, the change seems promising :-)

Cheers,

-- 
Aleksander