[PATCH 0/2] Add ResetProperties method to ConnectionContext interface

[PATCH 0/2] Add ResetProperties method to ConnectionContext interface

[Tommi Kenakkala]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

In some cases it is useful to reset connection context settings back to ones
ofono provisioning resolved initially.
What's your opinion on the API design, implementation and use-case described
next?

Deactivation of the context is obviously mandatory. The reasoning for placing
this into ofono is handling client requests consistently and avoiding race
conditions. Using this approach ofono does not re-activate the context, that's 
done by ConnMan or whatever connection manger the system uses.

Ps. Patches on behalf of Slava whose emails didn't get through to the mailing
list.

Slava Monich (2):
  gprs: Add ResetProperties method to ConnectionContext interface
  doc: Document ResetProperties method

 doc/connman-api.txt |    9 ++
 src/gprs.c          |  292 +++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 295 insertions(+), 6 deletions(-)

-- 
1.7.9.5

Re: [PATCH 0/2] Add ResetProperties method to ConnectionContext interface

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

Hi Tommi,

On 02/19/2015 05:59 AM, Tommi Kenakkala wrote:
> In some cases it is useful to reset connection context settings back to ones
> ofono provisioning resolved initially.
> What's your opinion on the API design, implementation and use-case described
> next?
>

Why don't you just remove the settings file and restart oFono?

> Deactivation of the context is obviously mandatory. The reasoning for placing
> this into ofono is handling client requests consistently and avoiding race
> conditions. Using this approach ofono does not re-activate the context, that's
> done by ConnMan or whatever connection manger the system uses.
>

I'm not so sure that this is a good idea.  A 'live' reset of the 
settings just seems wrong to me.  Why would you ever want to do that 
anyway?  If something is working, why bother resetting the settings?

oFono supports arbitrary number of contexts, so your UI can always add 
more.  So if you need to re-provision, let your UI handle this.  The UI 
should be capable of reading the provisioning database anyway in order 
to handle duplicates, etc.

Regards,
-Denis

Re: Re: [PATCH 0/2] Add ResetProperties method to ConnectionContext interface

[Tommi Kenakkala]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

> Date: Fri, 20 Feb 2015 10:00:31 -0600
> From: Denis Kenzior <denkenz@gmail.com>
> To: ofono(a)ofono.org
> Subject: Re: [PATCH 0/2] Add ResetProperties method to
>         ConnectionContext interface
> Message-ID: <54E75A1F.8070709@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Tommi,
>
> On 02/19/2015 05:59 AM, Tommi Kenakkala wrote:
>> In some cases it is useful to reset connection context settings back to ones
>> ofono provisioning resolved initially.
>> What's your opinion on the API design, implementation and use-case described
>> next?
>>
> Why don't you just remove the settings file and restart oFono?
oFono handles many other services so restarting would have undesirable effects.
For a moment clients would think there is no telephony at all: no SIM,
no cellular signal strength, no voice/emergency calls, no SIM ATK etc.

>> Deactivation of the context is obviously mandatory. The reasoning for placing
>> this into ofono is handling client requests consistently and avoiding race
>> conditions. Using this approach ofono does not re-activate the context, that's
>> done by ConnMan or whatever connection manger the system uses.
>>
> I'm not so sure that this is a good idea.  A 'live' reset of the
> settings just seems wrong to me.  Why would you ever want to do that
> anyway?  If something is working, why bother resetting the settings?
Generally speaking I agree with the point of view. The main point was
not the 'live' part, but to allow running provisioning again, e.g. if
user has set wrong ones.
FYI a MMS context may be active using a correct APN but messages don't
flow due to a wrong proxy. In such a case context remains active for
some time.

> oFono supports arbitrary number of contexts, so your UI can always add
> more.  So if you need to re-provision, let your UI handle this.  The UI
> should be capable of reading the provisioning database anyway in order
> to handle duplicates, etc.
When ofono already implements the initial provisioning logic it is not
tempting to duplicate it but instead trigger it again.
(A more suitable name for the new method could be  "ProvisiongContext"
or similar.)
If reverting provisioned settings is done by creating a new empty
context, one would still want to run ofono provisioning for that
(ofono restart not an option).
>
> Regards,
> -Denis

Thanks for your feedback Denis, I appreciate it. All tips to make
changes more upstream-worthy, or if not then otherwise better, are
welcome.

Thanks
-- 
Tommi

Re: [PATCH 0/2] Add ResetProperties method to ConnectionContext interface

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

Hi Tommi,

 >> Why don't you just remove the settings file and restart oFono?
> oFono handles many other services so restarting would have undesirable effects.
> For a moment clients would think there is no telephony at all: no SIM,
> no cellular signal strength, no voice/emergency calls, no SIM ATK etc.
>

Which is probably OK given that you're resetting cellular settings. 
Unless you expect the user to know / have control over very fine-grained 
details.

>>> Deactivation of the context is obviously mandatory. The reasoning for placing
>>> this into ofono is handling client requests consistently and avoiding race
>>> conditions. Using this approach ofono does not re-activate the context, that's
>>> done by ConnMan or whatever connection manger the system uses.
>>>
>> I'm not so sure that this is a good idea.  A 'live' reset of the
>> settings just seems wrong to me.  Why would you ever want to do that
>> anyway?  If something is working, why bother resetting the settings?
> Generally speaking I agree with the point of view. The main point was
> not the 'live' part, but to allow running provisioning again, e.g. if
> user has set wrong ones.

Then this has to be done with Powered = False as a prerequisite.  And 
you need some way to tell ConnMan what is happening and why.  Since 
someone still has to go in and activate the new contexts afterwards.

> FYI a MMS context may be active using a correct APN but messages don't
> flow due to a wrong proxy. In such a case context remains active for
> some time.

I don't get it, if the proxy is wrong, it must have been provisioned 
that way.  How is re-provisioning going to help?  Either way, it sounds 
like you want the UI to reset a particular context's settings, not 
everything.

>
>> oFono supports arbitrary number of contexts, so your UI can always add
>> more.  So if you need to re-provision, let your UI handle this.  The UI
>> should be capable of reading the provisioning database anyway in order
>> to handle duplicates, etc.
> When ofono already implements the initial provisioning logic it is not
> tempting to duplicate it but instead trigger it again.

Not tempting, no.  Provisioning is there to handle simple cases.  E.g. 
user receives new device, turns it on and gets connected.  If you want 
the user to mess with the settings, or if your database might contain 
ambiguous information, then you need to write a proper UI.  One that can 
read the provisioning database as well and present choices to the user.

> (A more suitable name for the new method could be  "ProvisiongContext"
> or similar.)
> If reverting provisioned settings is done by creating a new empty
> context, one would still want to run ofono provisioning for that
> (ofono restart not an option).

The problem is there's really no mapping between what the provisioning 
database returns and what the settings are right now.  You can sort of 
kludge around by comparing the context type, but you might be 
over-writing the wrong context.

The better way is to wipe all existing settings and re-populate.  But 
that would require quite a bit of ContextRemoved, ContextAdded signals 
to keep the clients consistent.

Might be easier to just re-boot the gprs atom.

Regards,
-Denis