On 5/14/18 11:19 AM, Jean-Yves Avenard wrote:
The proposed spec is available at https://wicg.github.io/media-capabilities/
<https://wicg.github.io/media-capabilities/>
I have some questions about this spec and our implementation:
1) What are the fingerprinting implications? What effect, if any, do
our "resist fingerprinting" preferences have on our API implementation
here? The spec tries to address this but as usualy mostly handwaves
around it.
2) It looks to me that given a MediaCapabilitiesInfo there is no way to
figure out what configuration it represents. Should there be such a
way? It seems like it would make it simpler to deal with asking for the
capabilities for several configurations at once and then examining the
results if you don't have to keep track of which returned promise
corresponds to which passed-in configuration. Doubly so if you
Promise.race things (though why one would do that in this case is not so
clear to me).
Note that even the example in section 5.1 of the spec gets this wrong:
it uses result.contentType, but "result" is a MediaCapabilitiesInfo and
doesn't have a .contentType property.
3) The booleans in MediaCapabilitiesInfo (apart from "supported") seem
rather vaguely defined. As a concrete example, if I am on 4-core (+
hyperthreading) "desktop"-level system with nothing running except the
video, "smooth" should clearly be set to true. Should it still be set
to true on the same hardware but in a situation where I am heavily
swapping and my load average is 150? This is a bit of a caricature, but
it seems to me that if people are going to treat this as a _reliable_
signal then it needs to be more clearly spelled out what things it does
or does not take into account.
4) For the "change" event on Screen, does that apply to any property
defined in any specification, not just the properties defined in this
specification? That would be a pretty significant monkeypatch in its
own right. It would be better if whatever specifications define
properties also define what events fire if those properties change.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
