Re: Network Information API

On Mon, Aug 16, 2021 at 2:50 AM Marcos Caceres <marcosc@w3.org> wrote:

> Thanks for attempting to pick this up again. My opinion/advice as someone
> involved with this API from the beginning...


Thanks a lot, greatly appreciated!


> The `sustainedSpeed` and `Sec-CH-Sustained-Speed` needs to go, IMO. If we
> can just get implementers to even agree on `metered`, that will be a
> significant achievement for interop.


One idea could be to let UAs report `Infinity` as a valid value for
`sustainedSpeed` if they don't want to report one of the more accurate
speed buckets.


> Also, consider the use cases (which are mostly misaligned with the
> original use cases for this API [1]):
>
>         • Instead of Retina resolution images use "regular" resolution
> images.
>         • Reduce the quality of lossy compressed images.
>         • Disable autoplay for foreground videos.
>         • Replace background videos with poster images.
>         • Request fewer or more results from a search API.
>
> The image ones should be handled by <picture> and <img> etc. IMO, we
> should refocus our energy there, not here.
>

As pointed out in the "Distinction from the save data use case" (
https://github.com/tomayac/netinfo/tree/relaunch#distinction-from-the-save-data-use-case),
these adaptive loading patterns are exactly that: adaptive. How would you
want to describe this (this being, for example: In general I have a Retina
device, but if the network doesn't permit Retina graphics right _now_, just
give me low-res images) in `<picture>` or `<img>`? @Addy Osmani
<addyo@google.com> has collected a lot of such adaptive loading patterns in
https://adaptive-loading.web.app/.


> Similarly, the video ones are better handled by adaptive video codecs (or
> the UA itself, in case where videos shouldn't auto play).


Yes, this is definitely not about adaptive streaming. It's more about
adaptive _loading_, for example, swapping a video for an image. For the
auto play case, UAs already have policies regarding this (
https://developer.mozilla.org/en-US/docs/Web/Media/Autoplay_guide#:~:text=For%20details%2C%20see,.)
that would not be affected by the proposal. For example, Chrome always
allows muted autoplay (
https://developer.chrome.com/blog/autoplay/#:~:text=Muted%20autoplay%20is%20always%20allowed.),
but in the case of bad network connectivity, rather than desperately force
the browser to fulfill the auto play desire the developer may have in the
general case, the developer could tell the UA to only even try this if the
network is good enough.


> Aim small, and build up from there.


Definitely :-)

Cheers,
Tom


> [1] https://www.w3.org/TR/netinfo-usecases/
>
>
> > On 13 Aug 2021, at 10:10 pm, Christiansen, Kenneth R <
> kenneth.r.christiansen@intel.com> wrote:
> >
> > (update Ilya's email address)
> > From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
> > Sent: Friday, August 13, 2021 2:09 PM
> > To: Thomas Steiner <tomac@google.com>; Kostiainen, Anssi <
> anssi.kostiainen@intel.com>
> > Cc: Ilya Grigorik <igrigorik@google.com>; Yoav Weiss <
> yoavweiss@google.com>; Addy Osmani <addyo@google.com>; TOREINI, EHSAN <
> ehsan.toreini@durham.ac.uk>; Noam Helfman <noamh@microsoft.com>; Yoav
> Weiss <yoav@yoav.ws>; Tarun Bansal <tbansal@google.com>; W3C Devices and
> Sensors WG <public-device-apis@w3.org>; Alex Russell <
> slightlyoff@chromium.org>
> > Subject: Re: Network Information API
> >
> > Very interesting Thomas!
> >
> > Great that you are picking this up.
> >
> > In the future we might want the ability to also give hints to the
> network connection, for instance Wi-Fi 7 will have Multi Link Operations
> where the applications can configure how they want to receive data per link
> at any time, like duplicate data for lower latency and more reliable
> connection (e.g. for game streaming and video calls) or data stream
> separate on multiple links to receive faster download speed. It is still
> around 3 years off, but it is something we should consider for the future
> (also future re-charters).
> >
> > Cheers
> > Kenneth
> > From: Thomas Steiner <tomac@google.com>
> > Sent: Friday, August 13, 2021 1:16 PM
> > To: Kostiainen, Anssi <anssi.kostiainen@intel.com>
> > Cc: Thomas Steiner <tomac@google.com>; Ilya Grigorik <
> igrigorik@google.com>; Yoav Weiss <yoavweiss@google.com>; Addy Osmani <
> addyo@google.com>; TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>; Noam
> Helfman <noamh@microsoft.com>; Yoav Weiss <yoav@yoav.ws>; Tarun Bansal <
> tbansal@google.com>; W3C Devices and Sensors WG <public-device-apis@w3.org
> >
> > Subject: Re: Network Information API
> >
> > Hi all,
> >
> > I have rebooted the Network Information API based on long-going
> discussions with @Yoav Weiss (who currently is still OoO):
> >       • Motivational doc:
> https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
> >       • Explainer:
> https://github.com/tomayac/netinfo/blob/relaunch/README.md
> >       • Spec draft:
> https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html
> > This is all in a relatively early stage, but I thought now would be a
> good time to get early feedback.
> >
> > Cheers,
> > Tom
> >
> > On Mon, Oct 26, 2020 at 11:04 AM Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
> > Hi All,
> >
> > I just opened two GH issues to discuss the DAS WG TPAC proceedings for
> the Network Information API.
> >
> > Maybe we'll move this discussion to the spec GH repo to have more
> eyeballs on the issues? See inline.
> >
> >> On 26. Oct 2020, at 11.09, Thomas Steiner <tomac@google.com> wrote:
> >>
> >> On Fri, Oct 23, 2020 at 4:51 PM Ilya Grigorik <igrigorik@google.com>
> wrote:
> >> Hey all.
> >>
> >> On Fri, Oct 23, 2020 at 5:12 AM Thomas Steiner <tomac@google.com>
> wrote:
> >> Thanks, all, for the responses so far. The initial question for @Ilya
> Grigorik still stands (whether there's still some active spec work
> happening).
> >>
> >> +Yoav Weiss captured it well, there is desire but no active spec work
> to address some of the lessons learned. If someone is willing to drive that
> process, that'd be great.
> >>
> >> Thanks for the update, Ilya! I guess it's up to the two WGs' chairs
> then to see if and how to collaborate on this spec then, right?
> >
> > https://github.com/WICG/netinfo/issues/88
> >
> >>  Also, thanks, Addy, for the household names, we definitely have some
> strong industry representatives in there and can thus say the use cases are
> indeed valid and on active use.
> >>
> >> For the use cases in fact, there's some great discussion happening
> already in issue 85, with the "metered" aspects being the topic of issue
> 84. So I guess we're in a theoretically good position to continue this
> discussion and just need to agree on a practical way as to the how. Is this
> an adequate summary of the state of affairs?
> >>
> >> Yes, I'd just caution not to over-index on the past backlog and first
> spend some quality time on unpacking lessons learned from what is already
> out there, and have a think on whether there is a simpler implementation
> that can satisfy the key needs whilst exposing less entropy.
> >>
> >> I agree. @Addy Osmani, are you in a position to provide some insights
> here? And @Yoav Weiss, you the WG members would probably have opinions on
> this, too. Is it worth opening an Issue to collect new use cases and
> another one to reflect on existing use cases?
> >
> > https://github.com/WICG/netinfo/issues/87
> >
> > Thanks,
> >
> > -Anssi (DAS WG co-chair)
> >
> >
> >
> > --
> > Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
> https://twitter.com/tomayac)
> >
> > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> > Registergericht und -nummer: Hamburg, HRB 86891
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.1.23 (GNU/Linux)
> >
> >
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
> hTtPs://xKcd.cOm/1181/
> > -----END PGP SIGNATURE-----
>
>

-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----