On 12/22/16 10:31 PM, mcace...@mozilla.com wrote:
(e.g., Boris' somewhat esoteric network setup)
Just to check, are you talking about my typical setup for accessing the
internet (which is totally non-esoteric laptop talks to wifi talks to
ISP) or the "privacy leak" cases?
> Most people have wifi at home
Right, that is _precisely_ my setup. (And claiming that it's a 600Mbit
or 6933.3 MBit connection as this API spec would require us to do is
nonsense on a pie plate, but maybe we're not talking about that column
of the nice table anymore?)
which is somewhat unmetered - and access to mobile data, which often costs more
(but not always true).
OK, sure, so we want the "does the user have to pay for this?" boolean.
The API sure goes out of its way to hide that information (e.g. you have
to know which of those transport types are typically metered or not)
_and_ make it not forward compatible (new types being added? business
models for existing types changing?).
The API, though ".type", allows the user and app to have a conversation about that:
"you want me to download stuff over mobile? Its might cost ya, but if you are ok with
it...".
If this is the use case we're trying to address, a "mayBeMetered"
boolean is the way to go, I believe.
Certainly things could be improved - but again, the API just addresses the
basic use cases
It addresses them _really_ badly, in my opinion.
However, if we do get better native integration in the platform (particularly
as it relates to multimedia assets), then this will be needed
Or a better API that provides the information people actually care
about? Yes, I realize there is a bit of an uphill battle to get people
to actually adopt the better API. I think in this case, this API is
sufficiently horrible that it's worth it...
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
