Draft Technical Report #30
Conversation
|
|
||
| This repo contains the WinterTC Runtime Keys ECMA Technical Report source and build tooling. | ||
|
|
||
| To get started, run `npm install` to install project dependencies |
There was a problem hiding this comment.
nit: maybe we want to recommend using npm ci instead? (to avoid modifying the existing lock file)
| <ul> | ||
| <li>Avoid being too similar to existing keys</li> | ||
| <li>Avoid similarity to common English words or offensive terms</li> | ||
| <li>Avoid being too generic or similar to general terminology such as "Web Runtimes", "Edge Runtimes", or "JavaScript Runtimes"</li> |
There was a problem hiding this comment.
Avoid being too generic or similar to general terminology such as "Web Runtimes", "Edge Runtimes", or "JavaScript Runtimes"
Is this a distinction for the name or the key? For example, there is this existing one (which may be "grandfathered" in, as I am assuming this is not retro-active)
{
"organization": "Azion",
"name": "Edge Functions",
"key": "azion",
"description": "Azion Edge Functions for ultra-low latency, edge-native applications, built with open standards for secure, high-performance serverless computing.",
"website": "https://www.azion.com/en/products/edge-functions/",
"repository": null,
"deprecated": false
},Would we maybe want to recommend existing entries to update?
There was a problem hiding this comment.
suggesting Azion update their name to "Azion Edge Functions" seems like a not-unreasonable move
There was a problem hiding this comment.
Yeah I believe the justification was that we didn't care about the name field. In fact, Netlify uses the exact same name, "Edge Functions". What really matters is the key since that is what everyone actually uses. Vercel, React, Arvan, Fastly, and Alibaba are other examples of names that are fairly ambiguous.
gesa
left a comment
gesa
left a comment
There was a problem hiding this comment.
Cloudflare's workerd is not ideal, it's too late to ask them to change that right?
| <emu-note> | ||
| <p>This section is generated from the machine-readable registry data (see <emu-xref href="#sec-machine-readable-registry"></emu-xref>). In the build process, this content should be dynamically generated from <code>runtime-keys.json</code>.</p> | ||
| </emu-note> | ||
|
|
There was a problem hiding this comment.
| <emu-note> | |
| <p>This section is generated from the machine-readable registry data (see <emu-xref href="#sec-machine-readable-registry"></emu-xref>). In the build process, this content should be dynamically generated from <code>runtime-keys.json</code>.</p> | |
| </emu-note> |
To clarify, you would remove the generated table from the version control markup once we're happy with the overall document, right?
There was a problem hiding this comment.
Yes - apologies for any confusion around that. The spec.html would be the like raw document that then the generated table would be injected into, when eventually a build script exists. I just had it in there to start with so we could get a sense for things.
| <li><strong>Organization</strong> (required): The organization or individual responsible for the runtime</li> | ||
| <li><strong>Name</strong> (required): The human-readable name of the runtime</li> | ||
| <li><strong>Key</strong> (required): The unique string identifier</li> | ||
| <li><strong>Description</strong> (required): A brief description of the runtime</li> |
There was a problem hiding this comment.
🤔 Should this use more precision than "brief" ? A maximum character length maybe? (similarly should all fields have a character length limit?)
There was a problem hiding this comment.
Also I think "required" is fine here, but if the secretariat raises any concerns, maybe we switch to "mandatory"?
|
What is wrong with Contrary to |
Authors an ECMA Technical Report for the future of runtime-keys work.
Closes: #23
Note: this is still heavily WIP; you're welcome to leave feedback but please know I'm still actively working on certain parts. This will be discussed at upcoming WinterTC meetings (first one will be January 23rd), so please attend those if you want to participate in the discussion.