Hi Ismo, > This is a philosophical difference from the provisioning point of > view. An operator will likely support multiple configured access > points, and the provisioning program should know their purpose from > the configuration file (internet/MMS/WAP/...). This metadata is not > there in the Ofono context, meaning that the provisioning program > needs to store somewhere else the mapping between Ofono context object > paths and the neccessary metadata. This begs the question: why not > store all connection data (APN, authentication data, other metadata) > to this external store in the first place?
Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. > In my proposal the "Status" variable was a three-state variable, > having the states "attached", "detached" and "suspended". "Suspended" > was specified to mean that the GPRS was attached, but temporarily not > available (for instance because of a 2G phone call or temporary loss > of cellular connectivity). In the IRC discussion someone said that > this property would not be part of Denis's API because the tri-state > variables were bad and the "suspended" status was not supported by So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. > spec 27.007. However, the problem is that Maemo 5 already has UI > support for indicating that the connection is suspended, and that > makes it harder to drop the feature. Could the "suspended" status enum > still be left there, and just have the modems that don't support the > feature to never go to "suspended" mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) > > Still one difference to my proposal was the dropping of the TX and RX > byte counts, and the explanation that those statistics would be > handled by the upper layers by reading the values from the network > interface. I mentioned the problem where the connection was terminated > by the network and the network interface was brought down before the > upper layer had a chance to read the values. After giving the matter > some thought, I still feel that for this reason the modem driver would > need to get the TX/RX data and send it to the upper levels, if at all > possible. Since many operators charge by the amount of data > transferred, not losing the TX/RX data is quite crucial. At least > Nokia phones have a GPRS data counter feature, that is supposed to > show the transferred data. This said, I know that not all modem > drivers can get the data from a connection that has been terminated by > the network, but that does not mean that the modem drivers that can > get the data should just discard it. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. Nokia hardware supports this explicitly, but many others don't. I don't want nasty kludges inside oFono to enable this. > > Btw, is the context API missing the PDP type (IPv4 or IPv6)? I left this out explicitly since I've never seen anything besides "IP" being used. But we can add this easily enough if there's need. Regards, -Denis _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
