w3c / mediacapture-handle

https://w3c.github.io/mediacapture-handle/
Other
14 stars 10 forks source link

The API proposed is insufficient to solve use case 1 #5

Closed jan-ivar closed 2 years ago

jan-ivar commented 2 years ago

The API proposed is insufficient to solve use case 1 in common situations that users would like. Users shouldn’t have to choose their presentation program to match the software provider of the meeting they plan to attend, for rudimentary slide controls to work. This would lead to development in silos, and would be a failure to standardize something basic.

See also https://github.com/WICG/capture-handle/issues/4

alvestrand commented 2 years ago

The API proposed solves the problem it sets out to solve. The messaging part does not need to be part of this specification; PostMessage(), peerConnection.dataChannel() and server-mediated messaging are all possible viable solutions.

I don't see this as a reasonable blocker for adoption,

eladalon1983 commented 2 years ago

Users shouldn’t have to choose their presentation program to match the software provider of the meeting they plan to attend, for rudimentary slide controls to work.

@dontcallmedom, I am concerned that this is stepping completely out-of-line. @jan-ivar has repeatedly tried to limit what businesses could do, and explicitly expressed intentions to block businesses from engaging in collaborations and business ventures, wanting instead to force their hand into his preferred models of cooperation. Can we loop in someone who is better versed in the principles and rules governing the W3C as a standards-setting body? I'd like to ensure we're all operating within our mandate and boundaries.

jan-ivar commented 2 years ago

https://github.com/WICG/capture-handle/issues/6#issuecomment-1043550366 seems relevant here.

eladalon1983 commented 2 years ago

#6 (comment) seems relevant here.

If a Web-developer is worried that they lack an API, then this Web-developers is welcome to propose that API, advocate its adoption by the W3C, and even implement the API in various open source browsers. That much is patently legitimate.

But can a W3C chair delay the adoption of an API because he wants to see another API make it to market first? Can a W3C chair decide whether businesses are allowed to engage in value-adding collaborations? Does the W3C deputize chairs to make such decisions?

There are important questions. I wish to learn the answers.

eladalon1983 commented 2 years ago

This discussion is proceeding over email. I am closing this issue so as to avoid confusion with other "use-case-1" issues and PRs, which have all now been resolved (for the time being).