Hi Youenn, Thank you for these thoughts. I have some counter-thoughts, but I am not sure this is the best forum to continue with the discussion. * Could you please explain the bottom-line Apple position for this API? * Could you please file issues in w3c/mediacapture-handle <https://github.com/w3c/mediacapture-handle/> for the issues, so that we may continue the discussion there?
Thanks, Elad On Fri, Mar 11, 2022 at 12:38 PM youenn fablet <youe...@gmail.com> wrote: > Hi Elad, > > For those following, the new link to the spec is > https://w3c.github.io/mediacapture-handle/identity/index.html. > > A few thoughts: > 1. The use cases are fine, although the proposal is currently restricted > to tabs having a tight coordination (same origin typically). Reducing a lot > the level of required coordination between capturee and capturer seems like > an important requirement. > 3. The current API allows to share a single string for all capturers no > matter the capturer origin (as long as origin is in the allowed list). It > seems that identity could be different depending on the capturer origin. > For instance, a capturee could expose its context ID ( > https://w3c.github.io/ServiceWorker/#client-id)) if capturer is same > origin but just its origin for all other capturers. Replacing the allowed > list mechanism by a map-like API would be more flexible without adding much > complexity. > 4. The idea is to share identity from captured page to capturer page. On > the web, the foundation of page identity is origin. The current API allows > exposing a partial identity, i.e. an application-provided string without > the origin. The scenarios in the document do not motivate AFAICS this > 'partial' identity. It seems origin should be the first thing a captured > page might want to share if it desires so. The fact that, by default, the > origin is not exposed is not encouraging either. > 5. Some of the usecases would be better suited with their own specific > solution (use case 3 and 4 for instance, a property that directly tells > whether capturee === capturer). I think they should be pursued on their own > and removed from the document. > 6. Capture handle creates a one way > broadcast/postMessage-limited-to-string mechanism if capturee repeatedly > calls the capture handle API as events will be fired on capturer for each > API call. If introducing a messaging API as use case #1 mentions, this > mechanism might become redundant with this future messaging API. It would > be good to consolidate the current proposal based on use case #1 next steps. > 7. Capture Handle Identity is really about screenshare, not about > camera/microphones, it would be good to make that clear in the links/spec > short names. > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
