ModemManager API review

[Marcel Holtmann <marcel holtmann org>]

Hi guys,

so during PlumbersConf Dan asked me to take a look at the ModemManager  
API and finally I got around it and have some initial comments. I  
wasn't able to actually use it to make data connections from my  
testing script, but initial results were kinda nice.

So the first thing that draw me off is that we are stupidly mapping  
the HAL devices 1:1 to our devices. That is wrong. We should not do  
this. So for example my Option card has three TTYs and one network  
device. This all is one device. Currently it shows up as three  
devices. The number of TTY (control, data or whatever) is an  
implementation and should not be exposed via the API. So we have to be  
smart with this.

The second thing is that the Manager interface talks about devices,  
while the main interface to the hardware is called Modem. So that  
should be consistent. Either we call them devices or modems.

The Modem interface has a Connect method call that takes a parameter  
number. This makes no sense whatsoever. Connect should not take any  
arguments it should connect with whatever has been configured or be  
smart and auto-configure it. Especially since you don't know if you  
are using a real number or actually an APN or something else.

And then we have Enable with a parameter. Don't do that. Just add  
Enable and Disable methods. Otherwise the API looks weird. Also  
signals like Connected, Enabled etc. are missing.

So the split between Modem interface and Gsm.Card make no real sense  
to me. I would just convert everything into properties or create a  
GetProperties method to retrieve one dictionary with all the  
information. All the GetImei, GetImsi calls only create round-trips to  
D-Bus that can be avoided. If one technology doesn't have IMSI, then  
this property is just missing.

And for setting things like the APN etc, you can use writable  
properties or a SetProperty method. So you could just set all  
properties and then call Connect. To make this fully async, a signal  
PropertyChanged would be needed, too.

And on that matter, please don't use enums since higher level  
languages don't really have the concept of includes from a C  
definition. So if you wanna give the band information you can just say  
"gsm900", "gsm1800" etc. Also for the mode having things like  
"connect", "connecting" etc. make it a lot easier to develop and  
debug. And when using dbus-monitor is shows up in clear text.

Some things like GetRegistrationInfo are just better separated into  
properties or key/value pairs in a dictionary. That keeps the API  
small and also flexible for future changes.

So the network details on GSM are not really that interesting at all.  
I would leave them out for now. However I do think that representing  
every network as object path would be a better approach here.

Regards

Marcel