Re: Call for Consensus (CfC) on Issue 17 of "Region Capture"

CropTarget production should be synchronous.

This is 100% feasible, since the only requirement is to provide an element
with a stable serializable identifier. One runs out of these after one runs
out of elements.

This spec has two steps: 1) get a handle to an element, and 2) input it to
the cropTo method. Only step 2 initiates cropping. Step 1 semantically
doesn’t. Step 1 should never take appreciable time.

Blocking on an IPC round trip ahead of exposing this simple handle makes no
sense from first principles.

It only makes sense in the combination of one implementation's premature
resource-using optimization, and that implementation's insistence on
exposing users to its limitations instead of hiding them by handling these
limitations itself using a fallback strategy.

Using Chrome's optimization as a design model for the API has the following
serious flaws:

   1. It invents a limited resource
   2. whose exhaustion defeats cropping, which can be exploited
   3. fear of exhaustion may discourage proactive usage (e.g. ahead of
   capture)
   4. needlessly delays postMessage
   5. opens more issues https://github.com/w3c/mediacapture-region/issues/48
   6. too complicated overall API surface (with error handling) for what it
   does
   7. goes against https://www.w3.org/TR/design-principles/#simplicity
   8. goes against https://www.w3.org/TR/design-principles/#synchronous

A synchronous API prevents these problems by not allowing them. Regarding
implementer inconvenience: the existing optimization seems fine if a simple
fallback is added to start minting CropTargets without pre-allocated
resources instead of failing, and have cropTo deal with it. This seems
feasible, because one can never run out of cropping.

On Mon, Jul 25, 2022 at 2:33 AM Youenn Fablet <youenn@apple.com> wrote:

> CropTarget production should be synchronous.
>
> Proof has been made that this API is implementable as a synchronous API
> without any particular hurdle.
> Web developers convenience prime UAs developers convenience.
> We also have sufficient experience to make such decision, I do not buy the
> ‘we never know’ argument.
>
>
> On 12 Jul 2022, at 09:34, Bernard Aboba <Bernard.Aboba@microsoft.com>
> wrote:
>
> This is a Call for Consensus (CfC) on Issue 17 of "Region Capture".
>
> Section 6.2 of the "Region Capture" specification contains a Note:
>
> [image: image.png]
>
> Issue 17 of "Region Capture" is available here:
> What makes CropTarget special to require an asynchronous creation? · Issue
> #17 · w3c/mediacapture-region · GitHub
> <https://github.com/w3c/mediacapture-region/issues/17>
>
> The Discussion of Issue 17 at the June 23 Virtual Interim is available
> here:
> WEBRTCWG-2022-06-23 - Google Slides
> <https://docs.google.com/presentation/d/1-SgzfMAeVG3u5vErJncC7OKDTGNDzSOMg_78LP8SULk/edit#slide=id.g131149eddb2_0_0>
>
> Minutes of the June 23 Virtual Interim are here:
> https://www.w3.org/2022/06/23-webrtc-minutes.html
>
> In replying to this CfC, respondents should indicate one of the following:
>
> * CropTarget production should be synchronous.
> * CropTarget production should be asynchronous.
>
> The CfC will last until July 26, 2022 at midnight Pacific Time.
>
> Bernard
> For the Chairs
>
>
>

-- 
.: Jan-Ivar :.