> of this discussion. I'd like all interested to comment.
> improvement? What is missing? What should be removed?
Here are some comments. Some of the comments were already present in
the IRC discussion, but I'll repeat them here anyway. First of all,
the both Denis's proposal and mine look quite much the same -- the
basic objects are the GPRS manager and the PDP contexts, and they
offer quite the same functionality. Please correct me if I understood
some parts of Denis's proposal incorrectly. The big differences
between the API proposals are the creation and connecting of the
contexts and the handling of the attached/detached state. I'll try to
address the both issues below.
In this proposal the contexts PDP contexts are persistent on the
device, meaning that they stay there also when Ofono is shut down. The
idea is that the contexts are made to Ofono by the GPRS provisioning
programs or by the UI, and then ConnMan or another upper layer needs
just to activate the context to actually do the connection. In my
proposal I thought that the higher layer components would keep track
of the access points and call the Connect() method with the suitable
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?
I mentioned that already. We do wanna store something like Type that
says internet, mms, wap etc. The only comment here was that for network
initiated context we have no idea of its intent.
The attachment to the GPRS network in this proposal is bit vague. To
my understanding, to attach the GPRS you need to set "Powered"
property on and "RoamingAllowed" on. To detach you need to set the
"Powered" property off. Since attaching can take a long time (or
fail), does this mean that the attach errors are handled in the
"Powered" property setter callback? Or what happens when (during
roaming) the "Powered" is already on and the user puts the
"RoamingAllowed" on -- where are the attach errors handled? I kind of
think that it might be a better idea to just expose the GPRS
registration status and the attach status, and let a higher level
component explicitly set the attach/detach with either a readwrite
property or Attach() and Detach() methods.
Powered = on and RoamingAllowed = yes and Roaming = true will lead to
Powered = on and RoamingAllowed = no and Roaming = true will lead to
Powered = on and Roaming = false will lead to auto-attach.
Powered = off will lead to detach.
We are not going to expose Attach() or Detach() method. As explained
there are global anyway and so pointless to expose. This can be handled
in the background without bothering the higher level application with
In my proposal the "Status" variable was a three-state
having the states "attached", "detached" and "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
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 am still not seeing the point in what suspended will do for us and the
UI. And that Maemo 5 exposed such a state in the UI is not an argument
to keep doing it. I asked this before, what are we suppose to be doing
when we get signaled suspended?
Still one difference to my proposal was the dropping of the TX and
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 is for ConnMan or similar to figure out. And we can always count
via netfilter or some other facility. Counting inside oFono makes no
sense. However we could send out a statistics signal before taking the
interface down if it would be really needed. Making it part of the
properties and having to poll for it is wrong.
Btw, is the context API missing the PDP type (IPv4 or IPv6)?
I keep forgetting these since so far I haven't seen any provider giving
me IPv6, but you are correct, we need to be able to handle this.
As I said, I think that the differences between this proposal and
are mostly philosophical -- should the context data be stored in Ofono
or in the upper layers of the stack? And should Ofono set the policies
(for instance the roaming case) or just act as a low-level interface
to the GPRS functionality?
While oFono is sort of low-level, it is not that low-level. If it would
we could expose the native AT commands. So in summary the PDP context
are stored persistently in oFono. Like BlueZ remember paired devices.
And for data roaming, we make it as simple as allowed = yes/no. This is
all the upper layer need to configure.
Not exposing method for attach/detach is a logical consequence as
explained above. It is a global per modem detail and thus there is not
point in exposing it. Also there is not point in having ConnMan and some
other potential application fighting for it. We do auto-attach if
available and tell the applications the status. If Attached = yes, then
the application can connect/disconnect contexts. As simple as that.
By looking at Denis's proposal it is easy to see that my
wasn't perfect either. ;-) At least the GPRS registration state and
possibly other properties need to be added to the D-Bus interface, and
the API also needs to be made more future-proof by thinking how the
network-initiated connections and the secondary contexts would be
I prefer start simple and add more details later. Removing details is
more complicated than adding them.