Re: Call for Adoption (CfA): "Capture Handle - Bootstrapping Collaboration when Screensharing"

After more careful review, I've filed some more issues I'd like to add to
my objection:

[1] https://github.com/WICG/capture-handle/issues/9
[2] https://github.com/WICG/capture-handle/issues/10
[3] https://github.com/WICG/capture-handle/issues/11
[4] https://github.com/WICG/capture-handle/issues/12

On Fri, Feb 11, 2022 at 12:09 PM Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> I object to adoption of the specification due to Issues filed in #3, #4,
> #5 and #6.
>
> The API proposed for adoption is not what we agreed to proceed with at the
> January WebRTC Virtual Interim Meeting.
>
> To summarize my objections:
>
>    1. Use case #1 is too broadly scoped by its headline: "Cross-app
>    communication" is a means to an end, not a use case. The use case as
>    written is “User drives a captured presentation app from a VC app” [1]
>
>    2. Use case #1 presumes tight integration. This is too narrowly
>    scoped. We should define the problem without preemptively limiting
>    solutions. [2]
>
>    3. The API proposed is insufficient to solve Use case #1 in common
>    situations that users would like. Users shouldn’t have to choose their
>    presentation program to match the software provider of the meeting they
>    plan to attend, for rudimentary slide controls to work. This would lead to
>    development in silos, and would be a failure to standardize something
>    basic. [3]
>
>    4. The API proposed for adoption is not what we agreed to proceed with
>    at the January WebRTC Virtual Interim [5]. It is missing the important
>    Actions [6] component, which through standardization won’t limit this
>    critical cross-app functionality to web properties owned by the same
>    corporation.
>
>    The Actions [6] presented are the template rudimentary “next",
>    “previous", “first", and “last” ones needed to advance slides from a VC (to
>    drive a tab-captured generic web presentation from another generic VC tab),
>    as an addition to the spec's “identification” section (which lets
>    properties partner to provide the same and more through tight integration
>    across specific products). [4]
>
> [1] https://github.com/WICG/capture-handle/issues/3
> [2] https://github.com/WICG/capture-handle/issues/4
> [3] https://github.com/WICG/capture-handle/issues/5
> [4] https://github.com/WICG/capture-handle/issues/6
> [5] https://www.w3.org/2022/01/18-webrtc-minutes.html#t06
> [6]
> https://docs.google.com/presentation/d/1j-RkOfgXPWxi8odvTLWqa_VR2QZ6-7sgLvKxOptw_Lk/edit#slide=id.g10da1807a11_11_47
>
> On Mon, Jan 31, 2022 at 1:32 PM Bernard Aboba <Bernard.Aboba@microsoft.com>
> wrote:
>
>> This is a Call for Adoption (CfA) of "Capture Handle - Bootstrapping
>> Collaboration when Screensharing".  The specification is available here:
>> https://wicg.github.io/capture-handle/
>>
>> The Github repo is here: WICG/capture-handle (github.com)
>> <https://github.com/wicg/capture-handle/>
>>
>> In response, please state one of the following:
>>
>>    - I support adoption of "Capture Handle - Bootstrapping Collaboration
>>    when ScreenSharing"
>>    - I object to adoption of the specification due to Issues filed in
>>    open bug <#number>
>>
>> The CfA will end on February 14, 2022 at midnight Pacific Time.
>>
>> Bernard
>>
>> For the Chairs
>>
>>
>>
>>
>
> --
> .: Jan-Ivar :.
>


-- 
.: Jan-Ivar :.