- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 31 Jan 2023 00:36:02 +0100
- To: public-webrtc@w3.org
On 1/30/23 11:16, T H Panton wrote: > I’m a bit concerned that we seem to have tightly coupled use cases with the production of agreed requirements. > > I’m not clear on the W3C process on this, but it seems to me that a use case can be valuable even without any new requirements. > > Even in situations where a use-case is already possible with existing APIs I think it can be useful to add it. > Such an addition has the following desireable results: > > 1) it flags up to web developers that webRTC -is- a valid solution to this use case > 2) it makes an implicit promise that this capability isn’t a quirk that will soon go away in a spec revision > 3) it raises the codepath as something a browser vendor might choose to optimise > 4) it encourages us to perhaps build on the existing APIs to (maybe only marginally) improve them for this use case. > > -By not including a use case that does exist and is in use we are sending a message to web devs that they are on risky ground and they should probably find a better way to meet the user need. > > Tim. I agree that documenting use cases is a Good Thing. We might want to drop the "NV" from the use cases document name, since it's the only place we collect use cases at the moment. Sometimes we discover requirements that aren't critical to accomplish an use case, but the APIs we have defined are awkward for the purpose (example: switching the payload type used for the RTP sender - currently it requires a SetCodecPreferences and an O/A cycle, while it should be as simple as just telling the sender which of the currently allowed PTs to use). Harald
Received on Monday, 30 January 2023 23:36:16 UTC