Layered APIs

[domenic]

Hello TAG！

I'm requesting a TAG review of:

• Name: Layered APIs
• Specification URL: Layered API infrastructure specification; this is also a general framework for future specs, but that spec lays the groundwork
• Explainer, Requirements Doc, or Example code: Layered APIs explainer; this explains the concept in general
• Tests: @hiroshige-g has some tentative tests in progress in the Chromium repo
• Primary contacts: @domenic, @ojanvafai, @drufball, @hiroshige-g

Further details:

• Relevant time constraints or deadlines: We are currently working to implement this behind a flag in Chrome, but it's still pretty early-stage and experimental.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is as follows:
  • No to all questions, except:
  • Does this specification enable new script execution/loading mechanisms? Arguably yes, although it does so via a modification of the existing script type=module mechanisms. This is used for loading built-in browser features using the same syntax, or loading fallback scripts. The first of these does not have any security concerns; the second goes through the normal module script loading path and so is taken care of by existing mechanisms.
• I have reviewed the TAG's API Design Principles

You should also know that...

The specific syntax, of using std:x|y module specifiers, is not set in stone. We are hoping to get wider feedback. Many alternate approaches were explored; another leading candidate is noted in the package name maps proposal. Thoughts welcome, although please do check the linked document to see if we've covered a specific suggestion before.

We'd prefer the TAG provide feedback as open issues in our Github repo for each point of feedback.

[torgo]

Agreed to discuss in depth at July f2f - invite people working on this.

[kenchris]

Hi there, is this an urgent review? As far as we understood from TPAC, you (@domenic) might have changed some of your opinions around this?

[travisleithead]

Some thoughts from our Paris F2F:

• In general, we love where we see this going, especially the latest updates we heard at TPAC.
• In the current doc, there's a fallback syntax (|) which sounds like it could be trouble in unsupported browsers, but more recent thinking appears to solve this much better with the package name maps proposals.
• Heard a suggestion at TPAC for the prefix to use for built-in modules: lib/ which really harmonized with me. Would prefer only this one prefix for now if possible--we can avoid name collisions through external processes.

Looking forward to seeing all these docs updated with your latest thinking. Let us know when we should take another detailed look!

[kenchris]

@travisleithead tc39/proposal-built-in-modules#12

[domenic]

It's probably best if this be closed in favor of #340.

[cynthia]

Thanks for letting us know!