W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: Network Information API

From: Laszlo Gombos <laszlo.gombos@gmail.com>
Date: Tue, 8 Jan 2013 23:28:13 -0500
Message-ID: <CAMRw=8VR7FbcH0CWfsZPRcknEnut03QX9DZDgur6mgbCiur2gA@mail.gmail.com>
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Cc: Niklas Widell <niklas.widell@ericsson.com>, Yoav Weiss <yoav@yoav.ws>, "SULLIVAN, BRYAN L (bs3131@att.com)" <bs3131@att.com>, Tobie Langel <tobie@fb.com>

I have some feedback on the Network Information API.

I think the name of the metered property does not reflect very well the
intention of the specification.

The way I read the specification an implementation can set the metered
property to true even if the connection cost is not charged based on the
amount of data used (e.g. a user-set preference to save bandwidth). At the
same time it is also possible for an implementation to set the metered
property to false even if the the connection cost is charged based on the
data used (e.g. bandwidth usage is well below the data limit threshold).

In general I see a value of choosing a property name that reflects better
that a "metered" (as defined by your monthly bill) connection is nothing
more than a hint - and it is not the definition of the attribute.

The best name I could come up with for the attribute is "bandwidthHint".

To echo Bryan's previous concern (
http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0021.html) I
propose to consider at least 3 values for this property:
 - none - no hint
 - preserve - optimize to save bandwidth (possibly a metered connection).
 - consume - assume that there is bandwidth for prefetching and other
optimization techniques that improves the user experience at the expense of
higher bandwidth cost.

WebGL has a somewhat similar model for an interface to control a similar
quality vs. speed trade off - see the hint function and mode argument.

Thoughts ? Better naming suggestions ?

Received on Wednesday, 9 January 2013 08:54:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC