<chair hat off>
Hey all!
I’ve heard some desire to change the fact that currently the Save-Data client hints are defined as part of the Network Information API. Save-Data is different than the other set of APIs defined there, as it represents the user’s preference rather than the network conditions.
Any objections? Support? General thoughts?
I support splitting out Save-Data as a separate header. It’s a request on a specific connection from the user system, more than exposing a property of the client’s network. I’d like to see clients that don’t want to support sending hints about their network be able to still request save-data resources.
I think it makes sense to define it separately. The purpose is different enough. That said, I do appreciate the convenience of querying it as part of the Network Information API, so I would not want to lose that feature.
For applications (like streaming video players) that make decisions about what to fetch from a field of alternatives, it is critical to be able to query that feature in JS, so that we can make decisions which respect it.
That said, it doesn’t need to be on the NetInfo API necessarily. But it should not be just a header. A JS API is important.
(not an indicator of support from Mozilla)
It would be good to split things out. There is still a lot of privacy concerns around NetInfo, so having this split out might be good (though it’s still a tracking data point, in that it reflects a user preference).
Getting back to this. I got a spec at https://github.com/yoavweiss/savedata
@marcosc - If that seems reasonable, can we bring it in to the WICG org?
Save data seems reasonable, but what do we do about the rest of the NetInfo API?
I plan to remove the save-data bits from it, once the separate save-data spec lands in WICG.
Sure, but I wonder is we should consider deprecating the remainder of NetInfo entirely after this. It would make NetInfo more palatable to Mozilla, and would fulfill some of the original use cases.