On Wed, Jul 14, 2010 at 03:56:14PM +0200, Daniel Wagner wrote:
> From: Daniel Wagner <[email protected]>
>
> Currently connman only has one set of counters for
> collecting statistics on online time and
> the amount of transfered bytes.
>
> For 3G connections we should destinguish between
> home network and roaming. This patch introduces
> two sets of counter values for home network
> and roaming network.
> ---
>
> First 'complete' version of this patch. I haven't yet tested the roaming with
> the
> 3G connection. From reading the code, only 3G would work right now.
>
> v2: - Added the juicy part, switching the stats according the state
> of service->roaming
> v1: - Rebase to head
> - Use two dictionaries home and roaming in Usage() as descriped in
> documentationw
> - Remove test-connman patch leftovers
> v0: - initial version
> - The Counter API should be done and is ready for review.
> - The inner logic is still missing.
I'm not so sure doing the home/roaming on service level is
correct. Consider following case: I'm travelling from Germany to Italy
for a couple of days and then to Switzerland. The roaming statistics
would not distinguish between Italy and Switzerland. The prolbem is
that the roaming costs are different for both countries. So I'd like
to have different statistics for both countries.
If I understand correctly the statistic counters should be in the
Network objects and not in the Service objects. Counter exposes the
Service as statistic source. Service could act as statistic proxy for
Network. In this case the Counter API doesn't have to change. But how
does this work out with different roaming counters? Counter API has
justs one home and _one_ roaming dict. Roaming counters could then
jump when we roam from one Network to another. At least the current
roaming ID would be nice to have. But then why not just expose only
one active statistic dictionary with an ID? It doesn't matter if home
or roaming.
Also the next question is how to access all stats, not only the
ready/online ones. IRC, we don't want to have them exposed as
properties in Network or Service. So Counter is the next place to a
feature like this.
The simplest version I can come up is something like this:
void GetAllStats()
Returns a list of known stats.
void GetStats(string name)
Return stats dict for given name.
But I don't like very much, somehow now really going well with the
rest of the API.
The next think I is alike the org.moblin.connman.Manager interface
which exposes all known Services through GetServices(). So there could
be something like GetCounters() in Manager which gives a list of all
Counters. Of course this would change the Counter Client interaction a
bit. Instead of creating a Counter only on request for a client there
would be all Counters available and a client just activates a Counter
to update itself.
If we want to keep the existing interaction we could do something like
CounterManager
+- Counter
+- Counter
+- ...
CounterManager
void Usage(object service, current stats dict)
The current used stats dictionary.
void GetCurrentCounter()
Returns the current used Counter object for statistics.
void GetAllCounters()
Return all Counter
What do you think?
thanks,
daniel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
