From: Daniel Wagner
---
doc/session-api.txt | 79 ++---
doc/session-overview.txt | 143 +-
2 files changed, 211 insertions(+), 11 deletions(-)
diff --git a/doc/session-api.txt b/doc/session-api.txt
index 3a0c9ca..d586856 10
Hi,
Here some questions about the Session API proposal. I admit don't get
the whole picture, and I'm missing all of your use cases. However, I
would not want to add any more complexity into ConnMan than what is
necessary.
On Thu, 2011-10-06 at 18:46 +0200, Daniel Wagner wrote:
> +
Hi,
> About the idle timeout I'm not sure we'd need per-session
> disconnections. If the app does not want or remember to inform ConnMan
> that it's usage is over, a per-bearer idle timer does the job reasonably
> well. If the app in question already stopped sending/receiving data, it
> wouldn't a
Hi Patrik
Thanks for taking time reading my proposal.
On 10/07/2011 11:32 AM, Patrik Flykt wrote:
> Here some questions about the Session API proposal. I admit don't get
> the whole picture, and I'm missing all of your use cases.
I feared I failed to explain it good enough. Hopefully I can clar
Hi Patrik,
> > +
> > + Applications which want to get a preconfigured
> > + session can pass in a ID with Manager.CreateSession().
>
> Preconfigured session? If applications don't know anything about
> sessions, would it be better to just go with free ride and
Hi Tomasz,
> > About the idle timeout I'm not sure we'd need per-session
> > disconnections. If the app does not want or remember to inform ConnMan
> > that it's usage is over, a per-bearer idle timer does the job reasonably
> > well. If the app in question already stopped sending/receiving data,
Hi Daniel,
> > Here some questions about the Session API proposal. I admit don't get
> > the whole picture, and I'm missing all of your use cases.
>
> I feared I failed to explain it good enough. Hopefully I can clarify
> some things.
>
> > However, I
> > would not want to add any more complexi
Hi,
On 10/07/2011 04:54 PM, Marcel Holtmann wrote:
>>> About the idle timeout I'm not sure we'd need per-session
>>> disconnections. If the app does not want or remember to inform ConnMan
>>> that it's usage is over, a per-bearer idle timer does the job reasonably
>>> well. If the app in question
Hi Marcel,
On 10/07/2011 05:03 PM, Marcel Holtmann wrote:
>>> Here some questions about the Session API proposal. I admit don't get
>>> the whole picture, and I'm missing all of your use cases.
>>
>> I feared I failed to explain it good enough. Hopefully I can clarify
>> some things.
>>
>>> Howev
Hi Daniel,
On 10/10/2011 11:13 AM, Daniel Wagner wrote:
Hi,
I think an IdleTimeout per Session makes sense. It should map to a
Service and not to a bearer, BTW. If you have for example a VPN tunnel
over a cellular link and the application is only interested in idle
timeout in the tunnel.
Hmm,
Hi Jukka,
On 10/10/2011 10:45 AM, Jukka Rissanen wrote:
>> I think an IdleTimeout per Session makes sense. It should map to a
>> Service and not to a bearer, BTW. If you have for example a VPN tunnel
>> over a cellular link and the application is only interested in idle
>> timeout in the tunnel.
>
Hi,
>> The end result is the same but the 2. is much easier to implement
>> (netfilter has already code for bearer specific idle timer and it was
>> used in maemo). Also in 2. the network connection (like wireless or
>> cellular one) is taken down faster which could help with power
>> consumption a
On Mon, 2011-10-10 at 11:11 +0200, Daniel Wagner wrote:
> Okay, let's implement the idle time out on a global level then, but
> keep the per Session IdleTimeout. Is that okay for everyone?
Did you mean the value is readable from the per-session IdleTimeout
attribute?
For setting the value of Idle
On 10/10/2011 11:31 AM, Patrik Flykt wrote:
> On Mon, 2011-10-10 at 11:11 +0200, Daniel Wagner wrote:
>> Okay, let's implement the idle time out on a global level then, but
>> keep the per Session IdleTimeout. Is that okay for everyone?
>
> Did you mean the value is readable from the per-session I
Hi Daniel,
> >> So coming to your question, the SessionId is used to get the correct
> >> configuration. BTW, for our use cases, the most interesting
> >> configuration part is the roaming one. So is an application allowed to
> >> use a roaming service or not. The application is still able to call
Hi Jukka,
> > I think an IdleTimeout per Session makes sense. It should map to a
> > Service and not to a bearer, BTW. If you have for example a VPN tunnel
> > over a cellular link and the application is only interested in idle
> > timeout in the tunnel.
>
> Hmm, perhaps I am not understand the u
Hi Tomasz,
> >> The end result is the same but the 2. is much easier to implement
> >> (netfilter has already code for bearer specific idle timer and it was
> >> used in maemo). Also in 2. the network connection (like wireless or
> >> cellular one) is taken down faster which could help with power
Hi Patrik,
> > Okay, let's implement the idle time out on a global level then, but
> > keep the per Session IdleTimeout. Is that okay for everyone?
>
> Did you mean the value is readable from the per-session IdleTimeout
> attribute?
>
> For setting the value of IdleTimeout, the application would
Hi
>>> Okay, let's implement the idle time out on a global level then, but keep
>>> the per Session IdleTimeout. Is that okay for everyone?
>>>
>>> If needed we can still change the implementation without the need to
>>> change the API.
>> I would definitely prefer that. And let's make the global,
Hi,
On Mon, 2011-10-10 at 08:15 -0700, Marcel Holtmann wrote:
> Step away from thinking that we will define and run a timeout for each
> session. That would be just waste. The values that the application
> sets on the session configuration are just hints. The choice on how to
> interpret
Hi Marcel,
On 10/10/2011 05:07 PM, Marcel Holtmann wrote:
So coming to your question, the SessionId is used to get the correct
configuration. BTW, for our use cases, the most interesting
configuration part is the roaming one. So is an application allowed to
use a roaming service or not. The appl
Hi Marcel,
On 10/11/2011 09:10 AM, Tomasz Bursztyka wrote:
Okay, let's implement the idle time out on a global level then, but keep
the per Session IdleTimeout. Is that okay for everyone?
If needed we can still change the implementation without the need to
change the API.
I would definitely pr
Hi,
On Tue, 2011-10-11 at 15:33 +0200, Daniel Wagner wrote:
> The apps do not direclty communicate with the internet. This is done
> in the Job Dispatcher.
Unfortunately I don't see the point with the Job Dispatcher in the
picture. If the intention is to further process application messa
Hi Patrik,
On 10/12/2011 10:29 AM, Patrik Flykt wrote:
On Tue, 2011-10-11 at 15:33 +0200, Daniel Wagner wrote:
The apps do not direclty communicate with the internet. This is done
in the Job Dispatcher.
Unfortunately I don't see the point with the Job Dispatcher in the
picture. If the intenti
On Wed, 2011-10-12 at 15:38 +0200, Daniel Wagner wrote:
> I am sorry if this has lead to very loud discussion in your office.
Nah, "shouted" was a too colorful expression, no voices raised, only
heads up to see the other person over one's monitor.
> My apology.
No apologies needed, since no har
25 matches
Mail list logo
