Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: NetworkStats API 2.0

11 views
Skip to first unread message

Jonas Sicking

unread,
May 20, 2013, 2:44:35 AM5/20/13
to Salvador de la Puente González, Hsin-Yi Tsai, dev-webapi, ALBERTO CRESPELL PEREZ, José Manuel Cantera Fonseca
Hi Guys,

I think the most important thing here is that we develop this API
together with whoever is going to be writing the UI code that will be
using this API. I.e. as long as this API works well for the people
writing the application code, I'm fine with it.

That said, a few things stood up when looking over this API:
* The names "find" and "slice" aren't very descriptive. As far as I
can tell, the two functions do exactly the same thing except one uses
database indexes to set start and end, whereas the other uses dates.
Is that correct? In general using indexes doesn't seem very useful to
me. If you want to display all history, couldn't you simply set the
start to a very old date? Or make the start optional?
* How is the start/end specified for addUsageAlarm? Using Date objects?
* Please coordinate with Hsin-Yi for the multi-sim stuff. I take it
that we want to store the data per-simcard and not per-simslot or
similar?

/ Jonas

On Thu, Apr 4, 2013 at 6:04 AM, Salvador de la Puente González
<s...@tid.es> wrote:
> Hello everybody
>
> Here is the new IDL proposal for NetworkStats API [1] that allows the user
> to recover information about transmitted and received bytes per interface.
> We are trying to enrich the current interface with those features detected
> while developing Usage / Cost Control application [2]. Furthermore, we need
> feedback for those in charge of the per-application data usage [3] to see if
> we can merge both APIs.<https://bugzilla.mozilla.org/show_bug.cgi?id=746073>
>
> Main changes are:
>
> * Support for multiple mobile statistics for each SIM in such a way it is
> transparent to the API's user.
> * Support for multi-SIM scenarios. We propose the NetworkInterface
> concept.
> * Support for back-end usage alarms.
> * Samples are now stored taking in count clock changes by using an
> always-increasing reference timestamp and storing the user timestamp
> separately.
> * Returned samples includes now total rx / tx bytes transmitted until
> date to always provide accurate information even when some samples has been
> deleted from DB due to size control mechanisms.
> * Now it is possible to query the database as it were an array by using a
> similar syntax to Array.slice() parameters.
>
> Users stories are provided in the etherpad [1] to support each new feature.
> Most of them are reflected in the interaction document [4] and others are
> only proposals.
>
> Please, feel free to provide any feedback you think is valuable.
>
> Thanks for your time and cheers!
>
> [1] https://etherpad.mozilla.org/network-statistics-api-2
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=858003
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=746073
> [4]
> https://www.dropbox.com/sh/z4aomhu09c1k4hu/yn-RrhgQtO/_Production/Interaction/Apps/Cost%20Control/OWD%20Data%20Usage%20V15%2020130212%20updated.pdf
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

Hsin-Yi Tsai

unread,
May 20, 2013, 3:14:44 AM5/20/13
to Jonas Sicking, ALBERTO CRESPELL PEREZ, dev-webapi, Salvador de la Puente González, José Manuel Cantera Fonseca

On 2013年05月20日 14:44, Jonas Sicking wrote:
> Hi Guys,
>
> I think the most important thing here is that we develop this API
> together with whoever is going to be writing the UI code that will be
> using this API. I.e. as long as this API works well for the people
> writing the application code, I'm fine with it.
>
> That said, a few things stood up when looking over this API:
> * The names "find" and "slice" aren't very descriptive. As far as I
> can tell, the two functions do exactly the same thing except one uses
> database indexes to set start and end, whereas the other uses dates.
> Is that correct? In general using indexes doesn't seem very useful to
> me. If you want to display all history, couldn't you simply set the
> start to a very old date? Or make the start optional?
> * How is the start/end specified for addUsageAlarm? Using Date objects?
> * Please coordinate with Hsin-Yi for the multi-sim stuff. I take it
> that we want to store the data per-simcard and not per-simslot or
> similar?

According to the usage and target of this API, I also agree that data
should be stored per simcard with definitely unique id.

Best regards,
Hsinyi

--
Hsin-Yi Tsai 蔡欣宜
Mozilla Taiwan
T: +886-2-87861100 ext:312
ht...@mozilla.com

Gene Lian

unread,
May 20, 2013, 4:05:22 AM5/20/13
to Jonas Sicking, dev-webapi, John Shih, ALBERTO CRESPELL PEREZ, Salvador de la Puente González, Hsin-Yi Tsai, José Manuel Cantera Fonseca
Please see my in-line response.

> On Thu, Apr 4, 2013 at 6:04 AM, Salvador de la Puente González
> <s...@tid.es> wrote:
> > Furthermore,
> > we need
> > feedback for those in charge of the per-application data usage [3]
> > to see if
> > we can merge both
> > APIs.<https://bugzilla.mozilla.org/show_bug.cgi?id=746073>

The work of metering network traffic per app has stopped for a while due to its low priority at the point in time. Indeed, we need to bring it back on the stage for the API 2.0. Basically, the design of per-app metering is almost the same as the original API except for an optional parameter: App ID.

John Shih (in Taipei office) has been taking over this task and working on that recently. He had pretty much work done at [1] and is trying to verify the per-app metering results and to re-organise the architecture with a better design.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=784575

Gene

Salvador de la Puente González

unread,
May 27, 2013, 6:27:02 AM5/27/13
to Jonas Sicking, José Manuel Cantera Fonseca, Hsin-Yi Tsai, ALBERTO CRESPELL PEREZ, dev-webapi
Hello everybody!

On 20/05/13 08:44, Jonas Sicking wrote:
> Hi Guys,
>
> I think the most important thing here is that we develop this API
> together with whoever is going to be writing the UI code that will be
> using this API. I.e. as long as this API works well for the people
> writing the application code, I'm fine with it.
I'm the one who is making the Gaia application ,)
> That said, a few things stood up when looking over this API:
> * The names "find" and "slice" aren't very descriptive.
I support the names are not very descriptive, let's think about a better
wording.
> As far as I
> can tell, the two functions do exactly the same thing except one uses
> database indexes to set start and end, whereas the other uses dates.
> Is that correct? In general using indexes doesn't seem very useful to
> me. If you want to display all history, couldn't you simply set the
> start to a very old date? Or make the start optional?
Slicing operation was very supported when we were tracking time changes.
Due to recent conversations with the UX team we moved to a simplest
approach and now it is not as necessary as before. Anyway, I think
having some way to manipulate the historical as a big array is good. We
have a user story when the user sets he wants to not track the period so
we are showing "the last 24 samples". It is quite simple to say

`slice(-24)`

rather than

`find(new Date().setTime(today.getTime() - 24*24*3600 * 1000), today)`.

Another possible API is to provide this:

`manager.fromDate().toDate()`

`manager.from().to()`

`manager.get()`
> * How is the start/end specified for addUsageAlarm? Using Date objects?
Yes.
> * Please coordinate with Hsin-Yi for the multi-sim stuff. I take it
> that we want to store the data per-simcard and not per-simslot or
> similar?
I already anwser Hsin-Yi.

Thank you very much.
>
> / Jonas
>
> On Thu, Apr 4, 2013 at 6:04 AM, Salvador de la Puente González
> <s...@tid.es> wrote:
>> Hello everybody
>>
>> Here is the new IDL proposal for NetworkStats API [1] that allows the user
>> to recover information about transmitted and received bytes per interface.
>> We are trying to enrich the current interface with those features detected
>> while developing Usage / Cost Control application [2]. Furthermore, we need
>> feedback for those in charge of the per-application data usage [3] to see if
>> we can merge both APIs.<https://bugzilla.mozilla.org/show_bug.cgi?id=746073>
>>

Hsin-Yi Tsai

unread,
Jun 11, 2013, 12:40:00 AM6/11/13
to Jonas Sicking, José Manuel Cantera Fonseca, ALBERTO CRESPELL PEREZ, Edgar Chen, Salvador de la Puente González, dev-webapi

On 2013年05月20日 15:14, Hsin-Yi Tsai wrote:
>
> On 2013年05月20日 14:44, Jonas Sicking wrote:
>> Hi Guys,
>>
>> I think the most important thing here is that we develop this API
>> together with whoever is going to be writing the UI code that will be
>> using this API. I.e. as long as this API works well for the people
>> writing the application code, I'm fine with it.
>>
>> That said, a few things stood up when looking over this API:
>> * The names "find" and "slice" aren't very descriptive. As far as I
>> can tell, the two functions do exactly the same thing except one uses
>> database indexes to set start and end, whereas the other uses dates.
>> Is that correct? In general using indexes doesn't seem very useful to
>> me. If you want to display all history, couldn't you simply set the
>> start to a very old date? Or make the start optional?
>> * How is the start/end specified for addUsageAlarm? Using Date objects?
>> * Please coordinate with Hsin-Yi for the multi-sim stuff. I take it
>> that we want to store the data per-simcard and not per-simslot or
>> similar?
>
> According to the usage and target of this API, I also agree that data
> should be stored per simcard with definitely unique id.
>

And we will need to revise nsINetworkManager::getNetworkInterfaceStats
or add another function to have mapping b/w a particular sim card and a
network interface.
0 new messages