Re: [w3ctag/design-reviews] State extension for JS Self-Profiling API. (Issue #682)

Thanks for the feedback, I tried to address the comments below ! 

> What is the story around user consent – because essentially you are using cycles on the user's device. Should it be gated behind a permission?

For the user consent story, this has been explored in the original tag review for the feature, reasoning is that this is a source of bias in the performance profile and it limits ability to profile first load.
See https://github.com/w3ctag/design-reviews/issues/366#issuecomment-496668592 

> what about main thread CPU starvation caused by a worker or an external process?

External processes are out of scope, the goal is to help developers understand how their own application behave in the wild. 
This include hotspots and unecessary code execution wasting the user's CPU cycles.

> ProfilerTrace and others should be annotated as serializable.

Thanks adding the annotations !

> Also why a document policy over a permission policy?

AFAIK at the time there was no 'disabled by default' support for Feature/Permission policy when this was added to the spec.
Also Document Policy header serves as very early signal to UA's JS engine that the document has intent to profile and start storing the necessary metadata.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/682#issuecomment-1083757184

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/682/1083757184@github.com>