On Mon, Dec 19, 2016 at 10:58 PM, <mcace...@mozilla.com> wrote:
> On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote:
> > On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote:
> > > On 12/15/16 12:20 PM, Ben Kelly wrote:
> > >>
> > >> Its more information than nothing.
> > >
> > >
> > > I'm not sure it is. At least when you have nothing you _know_ you have
> > > nothing, so might think about other ways to find out what you want to
> know.
> > > This way you think you know something but you don't.
> >
> > Agreed with Boris. "more information than nothing" is not an absolute
> > value, when that information is deceiving, which as others have
> > pointed out in this thread, is quite likely to occur with non-trivial
> > frequency in common uses of this API (the "if bandwidth>x then slow
> > download" example proves this point).
> >
> > E.g. a high % of the time, (most of the time when I'm not at home or
> > work), I am on a 4G (high bandwidth) mifi (metered cost).
> >
> > This API would report misleading results for me 100% of the time I am
> > on my mifi, and for anyone else on a 4G mifi.
>
> But you know you are on a mifi as a user: you bought the mifi, you paid
> for the mifi's contract, you connected to the mifi. Same with hotel wifi,
> etc. which may be metered.
>
> The point of the API is to allow the end-user and the application to
> negotiate when it's best to perform a download (not to make decisions about
> what is best and what is going to cost money). There is nothing preventing
> an app from asking the user what network type would be best to perform
> synchronization over.
>
> The general assumption that WIFI is cheap and 3G/4G may be sometimes
> wrong, but it holds for most users.
>
> > Real experience, all (AFAIK) the "sync to cloud automatically" code
> > out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
> > to turn all of it off or just not use it.
>
> Sure, but that goes back to Ehsan's point about perfect information: we
> can't currently get that until we get better WIFI standards or whatever.
> Until then, your mifi will look like WIFI - but that's not the APIs fault.
>
> Again, see the use cases document.
>
> > Let's learn from the error of "native" implementations/uses of this
> > kind of API / use thereof and not repeat that mistake on web,
> > certainly not ship an API that misleads web developers into doing the
> > wrong thing.
>
> The use cases document shows that native apps get this right a lot of the
> time.
>
> We are weighting the iCloud/DropBox problem against all the app examples
> given in the document. Right now, sites use a bunch of hacks to figure out
> if you are on a metered connection or not (see BBC example in the document).
>
> > >> Bluetooth networking is also a thing.
> > >
> > >
> > > That's a good point.
> > >
> > >> I think being able to distinguish this stuff provides some value even
> if
> > >> its not perfect for all cases. And I don't see how it causes any
> harm.
> > >
> > >
> > > I think it causes harm to give people information they have no business
> > > having ("wifi" vs "ethernet") and it does harm to given them
> information
> > > that's likely to be bogus (the last hop speed in the wifi/ethernet
> cases).
> >
> > Precisely. Obvious harms:
> >
> > 1. Privacy compromise without obvious user benefit
> > 2. Causes web apps to waste user bandwidth/financial resources
> >
> > If the response to that is "but doing it right is too hard", then
> > don't do it all.
> >
> > > Maybe the answer is that we should just reconsider the set of types
> that
> > > gets exposed and how they get mapped to connection speeds....
> >
> > I'm not sure that would sufficiently address harm 2.
> >
> > As far as I can tell, the only useful bit of information (as bz
> > pointed out) is the
> >
> > Am I on a cell data connection "for sure or maybe not"?
> > a) Where cell data "for sure" -> will *almost certainly cost the user*
> > b) Whereas "or maybe not" -> you have no idea whether it will cost the
> > user or not, do not make any assumptions.
> >
> > Given that the one pseudo-code example provided earlier in this thread
> > makes the mistake of using case (b) to errantly initiate bandwidth/$
> > wasting downloads (which may not even be necessary), I think this API
> > has not been well thought through in terms of actual user benefit, and
> > needs further incubation.
>
> Yeah, that's why it's currently in the WICG.
>
> > Not to mention we shouldn't even be getting to an "Intent to *ship*"
> > on something we expect to standardize that hasn't even been published
> > as a FPWD yet (which only *starts* the count-down clock to IPR
> > commitment).
>
> It was originally part of DAP, so it's actually gone through years of
> publication (first published in mid 2011):
> https://www.w3.org/TR/2011/WD-netinfo-api-20110607/
>
> All the arguments presented here also got raised by the WG, which made it
> go nowhere... so we took it to the WICG for further incubation - because
> Google shipped it, and thus we were hoping for buy in from some other
> browser vendor.
>
> > Implementing behind a flag should be good enough for prototyping
> > purposes to advocate for moving this from WICG to WPWG, and if that
> > transition doesn't happen for whatever reason it's a very clear sign
> > the tech is insufficiently incubated (or otherwise problematic) and we
> > shouldn't be shipping this. We're not even at that point yet!
>
> As above. This API has a very very very long history. It's been discussed
> to death and is suffering from standards-fatigue.
>
> Yes, it's kinda crap... but can get the job done for the documented use
> cases:
> https://www.w3.org/TR/netinfo-usecases/
I'm not really following this argument. Usually when a document has been
floating
around a long time but clearly has basic design issues and can't get
consensus,
even when a major vendor has implemented it, that's a sign that it
*shouldn't*
be standardized until those issues are resolved. That's not standards
fatigue,
it's the process working as designed.
None of this seems to add up to a strong argument that this functionality
should
be in Firefox
-Ekr
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
