Re: Proposal to abandon work on “Capture Handle - Bootstrapping collaboration when screen sharing”

Progress here is absolutely blocked, and disagreement is so fundamental, to
the point that we don't even agree on whether or not we agree. It looks
like there might be no way around either forking the document or
monkey-patching it, since we're not even tackling the same set of issues.

On Wed, Feb 8, 2023 at 12:23 AM Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On Tue, Feb 7, 2023 at 1:11 PM Elad Alon <eladalon@google.com> wrote:
>
>> On the one hand: "disagreements seem to be solely over final API shapes
>> to standardize."
>>
>
> Yes, as far as the state of consensus regarding existing deliverables,
> this seems accurate to me.
>
>
>> On the other hand: "I don't think we should solve more features for
>> loosely-coupled applications atm
>> <https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1285605351>
>> "
>>
>> There appears to be a contradiction here. It appears that at least some
>> disagreements are quite fundamental.
>>
>
> That's a comment on a proposal for new work. Even here, we seem to agree
> apps communicating information to a capturer may be desirable, and
> disagreement seems confined to API shape basically: whether the API should
> dictate the structure of such information or be left open-ended for
> applications to define. I expressed my preference for leaving it open-ended
> rather than getting into listing features.
>
> I don't see how this blocks progress or constitutes a "fundamental
> disagreement", since the central feature here is the open-endedness, not
> necessarily the structured part. It should suffice to enable apps to
> experiment about which features are good and which are not. If some
> features turn out popular, this might be good information to inform a later
> consideration for adding them.
>
> The major disagreement in that issue however, remains the shape, and I
> look forward to seeing my concerns with the current shape addressed
> https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1414120568
>
> I look forward to engaging with you and other members to resolve the
> remaining outstanding issues with the API, now that the uncertainty
> regarding the document has been resolved.
>
> Cheers,
>
>
>>
>> On Tue, Feb 7, 2023 at 5:51 PM Bernard Aboba <Bernard.Aboba@microsoft.com>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>> * The chairs have considered the proposal to abandon WEBRTC WG work on
>>> “Capture Handle - Bootstrapping collaboration when screen sharing”, which
>>> was presented at the January 17 WEBRTC WG virtual interim. We have
>>> concluded that there is no reason to issue a “Call for Consensus” (CfC).
>>> CfCs are generally issued to confirm consensus. Since the chairs at their
>>> discretion have already determined that no consensus exists for the
>>> proposal as currently formulated, we have concluded that issuing a CfC for
>>> stopping work in the WEBRTC WG is unnecessary. A Working Group’s scope of
>>> work is established in its charter, not in any single published document.
>>> Screen capture APIs remain in scope of this WG.  A WG can discontinue a
>>> document its members no longer have any interest in working on, in which
>>> case the document is frozen and remains. But this does not fit here, as the
>>> WG agrees the use cases are valid, and disagreements seem to be solely over
>>> final API shapes to standardize. The WG has heard no argument that the use
>>> cases are unimportant or that APIs to solve them should be stopped or
>>> unshipped for lack of interest. A WG can also send back to incubation a
>>> document it feels the WG is not ready to approach. But this also does not
>>> seem to fit here since APIs have shipped and general consensus exists for
>>> solving the problem the API solves. The chairs will monitor developments
>>> going forward. *
>>> Bernard
>>>
>>> For the Chairs
>>>
>>
>
> --
> .: Jan-Ivar :.
>