-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Principle: Use [Exposed=*]
to make only purely computational APIs available
#509
Comments
This sounds reasonable. I'm not sure if it needs to be a principle or could just be advice in the Web IDL standard. It might also be helpful to have some examples so people can evaluate whether they understand the rules correctly. |
As it so happens, I do have some examples to propose. The
The The |
I support having guidance for this. I think this is a good piece of guidance. I think Blob, as described, sits right on the line. |
Given the positive feedback so far, I've gone ahead and drafted a text for this in #510. |
(Given the File API discussion in WebApps at TPAC |
In the spirit of clarifying edge cases, what about
I'm guessing no, but I'm not sure I could articulate exactly what makes OffScreenCanvas or WebCodecs not pure computation (at least the subset of the APIs which doesn't do any network/on-screen rendering stuff). |
I'm less familiar with the above list, but I believe ImageBitmap's primary use is for drawing on a WebGPU and WebCodecs I don't know much about, but they also seem like they lose a lot of their usefulness if you don't have canvases and A/V pipelines respectively. I guess WebGPU can also be used for neural networks, but then there's also WebNN. |
It's certainly true that WebCodecs lose a lot of their usefulness without having somewhere to draw, but on the other hand I use WebNN might be broadly available someday, but there's already a lot of ML built on top of WebGPU now. I would guess a majority of WebGPU consumers are actually ML, since for rendering we already have WebGL. |
Assuming we go forward with this guidance, I suppose the maintainers of WebCodecs, WebGPU, and WebNN are now best positioned to decide whether they want to add |
Web Codecs isn't "purely computational", it can use lots of system calls, hardware facilities, and generally very little of the operations on Web Codecs have any notion of strictly bounded run time. Besides, it uses the event loop heavily, because almost everything is async in the API. When thinking if something could be Another way to frame this would be: "is this facility I want to expose only doing pure synchronous computation on the CPU, that has an execution duration that is going to depend solely on its arguments". |
All computation involves hardware and is not usually bounded-runtime, so I would still regard Web Codecs as purely computational under the normal meaning of those words. But "pure synchronous computation on the CPU, that has an execution duration that is going to depend solely on its arguments" sounds like a reasonable elaboration of @ptomato's proposed rule to me. Though that also suggests that perhaps ShadowRealm should be less restrictive than |
The normal meaning of those words on the web platform is as such: "hardware" means "hardware accelerated". The opposite on the web platform and in general is "in software", meaning, running on the CPU. This is how the words are used for canvas, gl, web codecs, and more. Here we're interested in workloads that are real-time safe-ish, and so we are interested in somewhat of a bounded run time. As things stand, Web Codecs doesn't tick the boxes for exposure everywhere, simply because it isn't sync and generally allocates (but some folks now would like a real-time safe API, see w3c/webcodecs#19 w3c/media-production-workshop#45 w3c/webrtc-encoded-transform#226). If an API isn't synchronous, it follows that it can't have a bounded run time (because the control will go back to the event loop or at the very least a microtask checkpoint, and that is unbounded). If an API allocates, it's the same deal: needing to allocate memory can be unbounded (and generally is). |
Right. My point is that "in hardware" vs "in software" was not originally part of the proposed rule, which was just about whether an API was purely computational, which I understand to mean something like "this API does not require any capabilities other than computation and memory to implement" (by contrast to, say,
Hm. |
|
OK, cool. If Thoughts on something like |
Alternatively, @annevk in this comment suggests maybe we shouldn't be worrying about trying to keep things out of audio worklets? But I don't know if that's currently the consensus opinion. |
I guess it shows that tc39/ecma262#1120 is still relevant and we haven't actually figured that out in a way that makes sense to everyone and doesn't create confusion. I don't think audio worklets are actively considered today for new language features (e.g., the new dependencies on the event loop) and they are also not actively considered for web platform features. But the latter is less problematic as there is a way to not expose those in audio worklets. I'm also not sure if the people developing audio worklets have the ability to maintain a strict boundary as it's easy for new things to sneak in. They would have to be ever vigilant across implementers. |
I'd like to move this forward. Based on the discussion above and on other things that have come up while looking at rationales for exposing or not exposing APIs, here are some things that might be able to be added to the design principle:
Does anyone feel strongly about adding any of these to the PR? |
As for the AudioWorklet question, I don't really have a strong opinion. That said, my goal here is to make the I get that there are conflicting positions ("AudioWorklets must not expose anything that isn't realtime safe" vs. "Well just don't do that then in AudioWorklets") and I think both of them are reasonable. Maybe this is something for the TAG to settle? |
Problem statement
In webidl#526 a new
Exposed
annotation,[Exposed=*]
, was introduced. It denotes a fundamental set of interfaces that are intended to be exposed in Window, all Workers, all Worklets, ShadowRealm, as well as any future global scopes.We've heard concerns (e.g., tc39/proposal-shadowrealm#401) that it's not clear when an interface should belong to this fundamental set and when it shouldn't. We'd like to issue guidance for this in a design principle.
I'm interested in feedback on the proposed guidance below, and am willing to write up the conclusions in a PR if it is generally positive.
Proposed guidance
[Exposed=*]
should be applied only to purely computational interfaces. That is, they do not perform I/O and do not affect the state of the user agent or the user's device.Anything annotated with
[SecureContext]
should not be exposed everywhere; not all global scopes are secure contexts.Anything relying on an event loop should not be exposed everywhere; not all global scopes have an event loop.
The
[Exposed=*]
annotation should also be applied conservatively. If an interface is not that useful without other interfaces that are not exposed everywhere, default to not exposing that interface as well.Further reading
Directly related, but predates
[Exposed=*]
: #35Discussion resulting in the addition of
[Exposed=*]
: webidl#468Other relevant reading: #325, #360, #448, tc39/ecma262#1120, WebAudio/web-audio-api#2499, tc39/proposal-shadowrealm#398
The text was updated successfully, but these errors were encountered: