Exposing an interface "on all globals"

[littledan]

For WebAssembly, I'm using WebIDL to specify the interface between WebAssembly and JavaScript in this PR. We're trying to avoid tying this into the Web Platform. One of the few ways that the current spec does tie into the Web is, to expose the interface to global objects, it uses [Exposed=(Window,Worker)].

What we really want for Wasm is for it to be exposed on all global objects. One aspect was accidentally omitting it on Worklets, but the bigger aspect is omitting it for everything that's not the web platform. For example, Node.js is likely to eventually enable Wasm support, and so the interface should be created on its global object as well.

I imagine that a version of Exposed which is everywhere might be useful for the Web Platform as well. APIs like TextEncoder which don't do any particular I/O wouldn't need a change each time another type of global object is added--they could be like new libraries added in the JavaScript standard.

What would you think about an additional extended attribute, or mode of using [Exposed], to support this case?

[domenic]

+1, I think it would be good to have a carefully-considered class of APIs available everywhere. The question is what the worklets folks think, IMO: would exposing e.g. URL or TextEncoder make sense in worklets? I think so, but want to make sure there wasn't some particular reason they were excluded.

[annevk]

Something like [AlwaysExposed] seems reasonable. What can use it besides wasm we can discuss separately I suppose, or do you want to have at least a couple consumers?

[tobie]

I'm not against this per se, but it seems to go against the idea of making sure editors carefully consider each place where their APIs are exposed (which I assumed we were championing when deciding to make [Exposed] mandatory). This might be mitigated by a combination of the following:

1. requesting editors to file an issue here when they want to use it,
2. have a checklist to make sure the API's a good fit,
3. have Bikeshed/ReSpec add a warning for those (that can somehow be turned off).
4. ?

[annevk]

I think requiring either is still good enough for that, coupled with implementer review. [AlwaysExposed] is effectively for standard library extensions.

[domenic]

Bikeshed: [Exposed=*]?

[tobie]

Bikeshed: [Exposed=*]?

Yeah, that was also my initial thought. I think the grammar let's us do it, too.

[littledan]

Thanks for your support here! Should I make a PR for [Exposed=*] ?

[tobie]

Sure. :)

[littledan]

I'm having trouble figuring out how the grammar supports [Exposed=*]. It seems like if you take a named argument, then * is not within the grammar of identifier; I'm not sure how any of the others would work either. Am I missing something? Otherwise, is it better to extend the grammar to include this, or to use [AlwaysExposed]?

[tobie]

So you want to add a 6th non-terminal to the group of non-terminals described in Extended attributes: ExtendedAttributeWildcard, which you'd define as:

ExtendedAttributeWildcard :
    identifier "=" "*"

Note this group of non-terminals is a bit special, as it's a subset of what the grammar allows for extended attributes. So you'll still want to add "*" to the Other non-terminal to make the main grammar work.

And I think you should be fine. (That's generally when @bzbarsky shows up to tell me I'm wrong, so you might want to wait a couple of hours.)

[bzbarsky]

At first glance, that sounds fine to me too.

[annevk]

@bfgeek @padenot could you say something about #468 (comment)?

I think worklets are intentionally small in their API surface and therefore I think the preference is that nothing additional is exposed there, unless it adds sufficient utility. It's not entirely clear they need URL parsing (e.g., they don't want fetch()) or text encoding/decoding.

[littledan]

I'd be curious about feedback for a couple other things:

• New JS features, such as ECMA-402 (Intl)
• The WebAssembly/JS API

I was assuming that we'd want to expose these everywhere, including worklets, but this assumption was made without checking with Worklet experts.

[padenot]

I think worklets are intentionally small in their API surface and therefore I think the preference is that nothing additional is exposed there, unless it adds sufficient utility. It's not entirely clear they need URL parsing (e.g., they don't want fetch()) or text encoding/decoding.

It is the current thinking of the Audio Working Group that indeed, we want the set of APIs available inside an AudioWorkletGlobalScope to be as minimal as possible. In particular, exposing APIs that can block execution for long periods of time or are asynchronous are not to be exposed.

In addition, my opinion is that it would be best to not expose API that would encourage mis-use of the AudioWorklet API. For example, string manipulation for internationalization or anything but executing WASM code is best done outside the worklet and transferred.

[littledan]

@padenot Currently, internationalization is being developed as an ad-on to the ECMAScript standard, and we don't even have notation for not exposing it in certain globals. Would you be interested in coming over to TC39 to explain the AudioWorkletGlobalScope requirements so we can make sure to accommodate them well? This could be through remotely attending a meeting over video conferencing, or filing an issue.

[padenot]

I can certainly do both, but I will kick things off with an issue on the link you provided.

Thanks!

[padenot]

I just opened tc39/ecma262#1120 for this.

[caitp]

I've put together a patch for WebCore in https://github.com/caitp/WebKit/pull/1/files, if anyone is interested in double checking my interpretation