Re: [RFC] GPRS context setup and teardown (doc/dataconnectionmanager-api.txt)

[Denis Kenzior <denkenz@gmail.com>]

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

Hi,

> > Lets suppose status=registered arrives and we're already attached.  Here
> > attached will be set to FALSE, Attached property will be set to false and
> > emitted.  gprs_netreg_update will presumably reset Attached back to True.
>
> Now I see it and you're absolutely right to be alerted, I set
> "attached" to the reverse of what it should be set to.  We're attached
> when we're either in REGISTERED or ROAMING state.  If I had done it
> right then the logic would look simple (I suppose):

I still don't believe that it works.  Suppose we're attached and registered.  
Now we get an indication that we're in 'searching' state.  set attach to true, 
compare with stored value (true).  Ah, don't do anything -> not good.

You also emit a signal that outright lies as to the current state.  Suppose 
we're registered and just the cellid / lac / technology changes.  This 
function still gets triggered and does a funky dance of emitting signals and 
calling into the driver to attach / detach.

>
> If either we already knew that we were in that state then there's
> nothing to do.  Otherwise we set the D-Bus property to reflect current
> state and call gprs_netreg_update to figure out if this is the state
> we really wanted to be in.

This part is fine, but lets make it easy to understand, e.g. do all of this 
inside gprs_netreg_update.

>
> If the notification indicates we were detached we will also need to
> reset all current contexts to inactive here, originally I did this in
> the driver.

Yes, this is one of the parts I forgot to port over :(

> This is a policy question, what do we do when the user disallowed
> roaming but the modem wants to roam?  If we decide that we will not
> retry to attach until the user pokes us again then "Powered" really
> should be reset to false because even if the conditions you listed are
> met we still won't attach.  Maybe instead we should do the retries
> with increasing timeouts like you mentioned in another message, and
> then "Powered" should stay set.

Resetting Powered in the core leads to strange situations where after coming 
from an overseas trip you'd need to reset Powered back to on.  I would find 
that annoying.

The nice thing is I don't think we need to play the attach/detach dance.  We 
can take advantage of the netreg atom's information.  If we're roaming there, 
we will be roaming on GPRS as well.  If we're registered there, then we should 
try to attach.

>
> An unrelated thing: you keep the allowed cid range in the core and
> only remember the min and max cid.  However I think (but don't know
> where to check for it) that +CGDCONT=? is free to return (1,2) instead
> of (1-2), or even (1-2,5-6,13).  Other AT commands do return ranges
> with this syntax.

You're absolutely correct that the syntax allows this.  My decision here was 
mostly a  matter of prudence.  I doubt any device actually uses a non-
contiguous cid range.  If/once we do find one that does, we can add a new 
set_sparse_range function (or something) in the core to take care of it.

Regards,
-Denis