- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 May 2022 09:14:48 +0000
- To: public-webrtc-logs@w3.org
> I think `CropTarget` with serialization and a possible future-path to stringification are good enough I disagree here, it does not make sense to do stringification on top of CropTarget. If the WG validates the use cases/support of strings, it seems best to deprecate the CropTarget APIs and go with a single string based API. > Assume the relevant element is garbage-collected but `token` and `uuid` are still alive The interesting case is when the element is still present, not when it went away. > How is `token` less concerning than `uuid`? If you GC `uuid`, it does not mean the actual `uuid` value is lost from the app knowledge, the app can reconstruct it. For instance the app might not store `uuid` but might store uuid.substring(0, 1)) and uuid.substring(1). It can later create a new `uuid2` representing the exact same string. Or it might store the uuid in IDB and query it later on. You cannot recreate a CropTarget like you can with strings. With strings, you will need to keep the mapping between the string and its element as long as the element is alive. With CropTarget, you will need to keep the mapping until either one of element or CropTarget go away. I would expect the lifetime of a CropTarget to be much shorter than the lifetime of an element. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/46#issuecomment-1134405049 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 May 2022 09:14:53 UTC