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
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 harm
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, bearer-based
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
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 already
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.
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.
Hmm,
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 and
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
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
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 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 need
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 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
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 let
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, it
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 complexity into
From: Daniel Wagner daniel.wag...@bmw-carit.de
---
doc/session-api.txt | 79 ++---
doc/session-overview.txt | 143 +-
2 files changed, 211 insertions(+), 11 deletions(-)
diff --git a/doc/session-api.txt
19 matches
Mail list logo
