Re: [mediacapture-transform] We shouldn't require track transferability (#113)

> > I'm not opposed to supporting transferability.
> 
> Great! Since you said tracks are useless on workers except for the worker API, does this mean you support the worker API?
> 

What is the Worker API?
I said tracks are useless on workers except for this API (i.e., mediacapture-transform) which artificially requires them.
So, to clarify, there nothing I support about mediacapture-transform in its current form.

> > I'm opposed to making it a requirement to use mediacapture-transform, ...
> 
> It already is a requirement.
> 

An artificial requirement.  It would be very easy to have a spec that does not require track transferability for worker support. That also applies to new implementations (or updating existing ones), since the proposed approach is based on pre-existing patterns already implemented by all major browser engines.

> > ... as that will have the practical consequence of delaying interoperable implementations.
> 
> I doubt attempting to standardize a third new API and waiting for three implementations will get us to interop quicker.
> 

I also doubt an API that ignores developer requirements and concerns by at least one implementor will get us to interop.


> Safari has shipped, and Firefox is working on it. 1½ < 3 + one WG. I've filed [w3c/mediacapture-extensions#158](https://github.com/w3c/mediacapture-extensions/issues/158) to help.
> 

https://github.com/w3c/mediacapture-extensions/issues/158 does not address this issue.

> Creating a permanent web API to solve one implementer's short-term scheduling seems against [§ 1.7. Add new capabilities with care](https://w3ctag.github.io/design-principles/#new-features) and [§ 1.9. Leave the web better than you found it](https://w3ctag.github.io/design-principles/#leave-the-web-better).
> 

The specific change proposed in this issue is not about "short-term" scheduling. It is to make the API better. 
If a use case can be solved appropriately without introducing a dependency on another feature, then it is better to solve it without introducing that dependency. The fact that it results in an API that is easier to implement is a consequence of that design being better. Another benefit is that it allows easier feature detection on Window, more in line with [2.5. New features should be detectable](https://w3ctag.github.io/design-principles/#feature-detect) than the current version of the API.

Ignoring the needs of web page authors and at least one user agent implementor, which the current API does overall, is directly against [1.1. Put user needs first (Priority of Constituencies)](https://w3ctag.github.io/design-principles/#priority-of-constituencies).
Ignoring concerns of user agent implementors also goes against [1.1. Put user needs first (Priority of Constituencies)](https://w3ctag.github.io/design-principles/#priority-of-constituencies).

_User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity._

The track transferability requirement is IMO the opposite of [§ 1.7. Add new capabilities with care](https://w3ctag.github.io/design-principles/#new-features). That principle refers to adding _"new capabilities to the web with consideration of existing functionality and content"_.  Adding a feature that requires a dependency on another feature is not better than adding the feature following existing patterns that don't require such dependency.

> > This doesn't mean applications are forbidden from transferring tracks on browsers that support it if they want to.
> 
> Having web developers navigate between 3 instead of 2 different APIs to do the same thing sounds worse, not better.

What 3 different APIs?

Are you referring to the requirement of using AudioWorklet for audio processing, which is a different API that, in addition, is not suitable for all types of processing?


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2444153804 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 29 October 2024 13:00:50 UTC