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

> @guidou I appreciate your efforts to simplify the API, but I believe your proposal introduces more complexity rather than reducing it. 

Can you elaborate on how is it more complex? Especially for Web developers.
One way would be to compare how intended use cases are implemented with each API. 

> It seems unclear whether your proposed API is intended to replace the existing MediaCapture Transform API or to coexist alongside it.

It can be both. I would prefer replace.

> If it's meant to coexist, then we're asking developers to navigate between multiple APIs that achieve similar goals, which can lead to confusion and fragmentation. 

It would be better to replace, but since there is one implementation, coexist seems acceptable.

> This also increases the burden on browser implementers to support multiple APIs, delaying interoperability.
It's not uncommon for an API to have multiple constructors or factory methods to serve different use cases.  
In this case, I'm proposing factory methods that the provide the following benefits:
* It properly supports all use cases that have been presented so far. In particular it is better at supporting the common use case of an application wanting to manage the track Window and media processing on Worker.
* It removes the tight coupling between two separate API. This has the advantage that they can be developed independently by UA implementers.

> If it's meant to replace the existing API, it disregards the implementations already shipped in Safari and in progress in Firefox, which would fragment the ecosystem further and negate the developer feedback we've already received.

For this reason, coexist would be acceptable.

> Moreover, your proposal doesn't seem to stand on its own because it doesn't cover all the use cases the current API does — particularly future scenarios where tracks originate in workers or need to be fully managed within a worker context.

I'm talking about real use cases deployed in production right now, not hypothetical ones that might never exist. I believe the former should have more weight than the latter in the design of the WG's APIs.

> Requiring track transferability isn't an unnecessary dependency;

Requiring track transferability for use cases that don't need it is indeed an unnecessary dependency.

> it's a design choice that provides significant benefits to developers, such as simplified lifetime and configuration management, as well as access to track stats and settings directly within the worker.

There is no simplified lifetime and configuration management. Any use case that prefers to manage track lifetime on Window (basically all use cases deployed today) requires much more complex lifetime management with the existing API.

> Adding another API also goes against the web platform design principles of keeping the platform consistent and avoiding unnecessary complexity.

Requiring track transferability for use cases that don't need it is precisely adding unnecessary complexity.

> I believe it's better for us to focus on implementing the existing API consistently across browsers and addressing any implementation challenges together, rather than introducing an alternative that could fragment the ecosystem.

The ecosystem is already fragmented. This proposal might have the side effect of making it easier to reduce that fragmentation as it makes it possible for UA implementors to develop two features independently using patterns that are already implemented and tested. Forcing two features than can (and should) be orthogonal to have a dependency such that one has to be implemented before the other does nothing to help reduce the already existing fragmentation.

Finally, I think we have reached the point in which we are just repeating the same arguments without achieving consensus. Shouldn't we go ahead with the plan to file our positions in separate issues and get TAG's input? 


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


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

Received on Wednesday, 30 October 2024 19:58:07 UTC