Meeting minutes
Media Session - Add a way of detecting which actions a UA supports
Issue #228 - Add a way of detecting which actions a UA supports
cpn: One question on this. Is this simply a dev ergonomics question, to have an explicit API rather than using exceptions?
beaufortfrancois: I would prefer to avoid exceptions, but can live with it. The problem is if your app crashes because you forgot the try... catch...
… This may crash the entire app in another browser
… Jan-Ivar proposed something entirely new in the thread, not sure I want to change the shape just for that.
cpn: Neither Jan-Ivar nor Jer are around.
… Can others speak to this issue?
padenot: From Mozilla's perspective, I haven't been following, Jan-Ivar is the one tracking this.
cpn: OK, I suspect we'll need to find another time to discuss.
… I observe that Domenic suggests in this thread that try... catch... would be sufficient
… I don't have a strong view on that.
… Adding a query mechanism does not seem controversial to me but others may disagree
beaufortfrancois: One thing is that your browser may support the enum without supporting the underlying feature. The API would handle that scenario.
cpn: That's interesting as well. Because in that case, the try... catch... approach would not work.
beaufortfrancois: exactly.
tidoust: From a Web IDL testing perspective, test will fail if enum values are not supported, regardless of whether the actual underlying feature is supported
cpn: OK, let's discuss that next time when everybody's around.
Media Source Extensions - Publication as FPWD
MattWolenetz: Francois, Chris and I have been chatting on email. The initial expectation was that changeType was the only technical change that needed to land in the spec to start the FPWD transition process.
… I missed a couple of meetings where this was discussed. changeType has landed in the spec and shipped.
… There's also MSE-in-worker that is about to land in the spec.
… There are other features that are planned, such as playback through unbuffered time ranges. My expectation was that this didn't need to be in the draft before publication of the FPWD.
… Any particular blocker that people feel should be addressed before publication of FPWD?
cpn: My understanding is that publication as FPWD triggers a patent exclusion period, so assessment is whether planned features are large enough that they should be in there before we publish the FPWD.
tidoust: the call for exclusion happens on FPWD, the next opportunity is when we publish a CR snapshot. The idea is to find a balance between shipping a spec that's not advanced enough, and one that's too advanced
… Publishing doesn't mean you can't add features later. If we move fast enough, we can publish CR snapshots, and each one can trigger a call for exclusions
MattWolenetz: I was waiting for Mark Watson to review the MSE-in-workers feature. There are other pieces of the spec that would be coming, such as privacy and security.
… Do you think that MSE-in-workers need to be in the draft before publication?
tidoust: What matters is to make sure that we have group consensus and that the set of features that will be in the FPWD is clear.
MattWolenetz: I don't think that MSE-in-workers need to be in the spec for FPWD.
cpn: There will be other opportunities for exclusions
tidoust: Certainly not mandatory but I note that I would take the opposite approach and actually merge MSE-in-workers as-is, even if it is imperfect, to have the feature included in the patent exclusion period. Just my two cents.
MattWolenetz: OK, that all depends on when we can merge the MSE-in-workers PR then, so that we can issue the CfC.
markw: I will try to review as soon as possible
padenot: I am available to review as well, as initial work on WebCodecs is wrapping up.
tidoust: we could run the CfC in parallel with reviewing the MSE in Worker PR, so could do the CfC right away
cpn: From a chair point of view, I'd be happy with that. I will follow-up with Jer after the meeting. CfC with "publish as FPWD with both changeType and MSE-in-workers".
chcunningham: Technical question: How are you planning to edit v2? Copy the entire v1 spec, or is it going to be a delta?
MattWolenetz: The v2 contains the entire v1 spec.
chcunningham: Is the final stage that we'll have a Recommendation that includes both v1 and v2 features?
MattWolenetz: That is my understanding.
… Any concern about this?
chcunningham: Just curious how it works.
MattWolenetz: There was a discussion about having a separate repo for v2, but that seemed overkill.
cpn: Related, there was a question about whether we would use a "media-source-2" shortname in /TR. My understanding is that we would continue to use "media-source".
MattWolenetz: It may help to highlight that there is a v2 with an explicit version number.
tidoust: CSS specs are examples. Fewer in the API world have versioning including. So it's up to the group. Personally, I think versioning isn't needed, it may complicate more than add value
… The SotD section would explain this. We'd have a custom paragraph that explains it's a new version with additional features. We'd need that before publication in any case
MattWolenetz: I don't think a delta spec would be appropriate. There are lot of changes such as respec, internal slots, that would make a delta spec look bad
tidoust: I'd recommend against delta specs. They often copy from the main spec, makes things hard to find
chcunningham: I would stick to simple
cpn: I guess we can include the plan to stick to "media-source" in the CfC
markw: Regarding MSE issue 37, I wonder whether this could be included in v2, assuming that we have someone who could provide spec content.
… Sample-frame accurate instead of coded-frame accurate for audio.
MattWolenetz: It may not be accepted by all as a normative requirement, but that's v2 for me indeed.
markw: I understand that, that would be an option.
… I think it is slightly more than gapless playback. appendWindow is interpreted in terms of coded frames. There is no way for a site to provide the info "in the middle of the coded frame". appendWindow in the middle of the frame should actually be meaningful.
MattWolenetz: I agree, that's what I was trying to say. That's what Chrome does, but it's normatively not in the spec.
… Standardized testing against that would be awesome too, crucial to get interoperable gapless experiences.
Next call
cpn: Next call will be September 14th. Please let us know agenda items before that meeting.
[Call adjourned]