Hi Antti, > > > > > But then it is far simpler to have a D-Bus getter and a D-Bus signal > > > > > by any > > > > > sane measure of complexity. > > > > > > > > So you did consider the complexity on both sides, ofonod and timed? And > > > > not just looked at one side of picture? > > > > > > Timed also needs to follow the registration status, namely the MNC/MCC > > > of the registered network. This information it needs to be able to find > > > the correct timezone, as the UTC offset alone only indicates the > > > geographic longitude for the timezone. > > > > > > Factor that in to the equation, and timed already needs to enumerate > > > available modems, call GetProperties, and listen to the > > > NetworkRegistration interface's PropertyChanged signals. > > > > > > However, if we refactor the time plugin to also send the MNC/MCC pair -- > > > or better yet, the ISO country code based on MCC or even the actual > > > timezone from matching zone.tab entry -- then following netreg is no > > > longer needed. > > > > > > *Then* I agree a method call is actually a lot simpler from timed point > > > of view; all it needs to do is implement a single method on some > > > org.ofono.NetworkTimeConsumer interface and not worry about enumerating > > > modems via ModemManager or listening on any signals. > > > > we are doing the country alpha2 matching to MCC already in ConnMan for > > the WiFi regulatory enforcement update. I am not sure that I wanna copy > > these tables around all the time. > > > > So the struct ofono_nettime_context has already a reference to struct > > ofono_modem, so why not add a reference to the struct ofono_netreg and > > then you have the MCC/MNC details available inside the plugin.
one additional comment here about getting the MCC and MNC (or other atom details). You can use __ofono_modem_find_atom() to get the netreg atom from the modem pointer. This means that any nettime plugin already has all the needed information available. > If I would like to do conversion from mcc to alpha2 in ofono, what would > be your suggestion for doing this. I noticed that in connman you have > mcc.h that contains the mapping array, but in ofono we don't have such > an array. As a temporary solution, would it be feasible to just import > the mcc.h to ofono until a more generic solution is implemented? I don't even like the fact that we imported it in ConnMan. That might have been a mistake actually. I really prefer to have that on the filesystem and we just mmap() it. And it is up to the distribution to provide such a file. We do a similar thing with OUI for BlueZ, so that is clearly the better approach here. Regards Marcel _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
