- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 26 Apr 2018 17:15:27 +0000 (UTC)
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/276@github.com>
Hello TAGļ¼ I'm requesting a TAG review of: - Name: Layered APIs - Specification URL: [Layered API infrastructure specification](https://github.com/drufball/layered-apis/blob/master/spec.md); this is also a general framework for future specs, but that spec lays the groundwork - Explainer, Requirements Doc, or Example code: [Layered APIs explainer](https://github.com/drufball/layered-apis/blob/master/README.md); this explains the concept in general - Tests: @hiroshige-g has some [tentative tests in progress](https://chromium-review.googlesource.com/c/chromium/src/+/1013322) 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](https://www.w3.org/TR/security-privacy-questionnaire/). 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](https://w3ctag.github.io/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](https://docs.google.com/document/d/1jRQjQP8DmV7RL75u_67ps3SB1sjfa1bFZmbCMfJCvrM/edit?usp=sharing); another leading candidate is [noted in the package name maps proposal](https://github.com/domenic/package-name-maps#supplying-fallbacks-for-host-supplied-standard-library-packages). 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/276
Received on Thursday, 26 April 2018 17:15:52 UTC