Re: [w3ctag/design-reviews] Media Source Extensions for WebCodecs (#576)

> > Did y'all have any feedback on whether these new append methods should be added as promise based? Should the interface use the non-promise style (updating, updateend events) for consistency until byte-based promise methods are available? Should we only add the promise based method for chunks once we have a promise based method for bytes?
> 
> @plinss, @atanassov and I discussed during our VF2F today. And one of the concerns we had were if promises would provide the latency guarantees that the downstream application needs (given that current MSE is event driven, it should be okay?), 

Since the current MSE is event driven, I don't expect worsened latency due to apps instead awaiting Promise resolution/rejection via this new promise-based method for appending chunks versus what that latency would have been had it been event driven chunk-appending instead. In passing, I've heard that at least some MSE API users have already wrapped the existing event-driven byte-based append operations inside promises in their applications.
Note also that the ergonomics of a promise-based API are simpler, too: the extra enqueueing of 'updatestart', and 'update' events are not done (nor 'abort' or 'error' in those rejection paths). It is unclear if existing API users depend on those events, or if their absence is negligible.

> and if a domain specific application of promises would make it painful to upgrade when byte-based promises are available. We don't have a strong preference for either, but we'd like to hear your thoughts on this.

I'm not sure I understand this portion of your response. If and when Promisified versions of MSE `appendBuffer()` is available, it's unlikely that the event-driven versions would be deprecated. Hence, upgrading from event-driven to promisified byte-based append would not necessarily require urgent prioritization by the MSE API user, though (apart from the lack of probably superfluous extra events) there would not be a big change of actual functionality made available by the Promisified versions of those methods. I feel like I'm missing your point though. 

> Does the current design propose a generic path forward for a byte-based promise API? If so, we think promises are probably the right answer.

The path taken in MSE-for-WebCodecs' `appendEncodedChunks()` lays out a pattern that indeed could be followed by a Promisified version of the existing event-driven byte-based `appendBuffer()`: the draft specification PR (https://github.com/w3c/media-source/pull/302) for the Promise portion of the new `appendEncodedChunks()` reuses much of the existing state machine structure: at most one asynchronous operation can be in-flight at a time for a particular `SourceBuffer`, with well-defined start/complete/error/abort paths for the existing event-driven async operation (and now also for the Promisified `appendEncodedChunks()` async operation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/576#issuecomment-932235581