A while back in #222 and #169 we talked about the idea of having some prefix.
Recent discussions about prefixes have led to a polarizing debate between "prefix" and "namespace" notations — for things that are not necessarily the same thing.
- You do
file://… if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs)
- You do
https://… if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs, and potentially lawsuits)
- You do
mailto: if the implementation supports the scheme — I don’t think a good implementation wants this to lead to a network request by the browser context itself
If you have a scheme, it can have zero network-transport and yet an implementation can make it very very meaningful to one loader.
You see this with blobs today — they are memory things — they cannot extend beyond the lifespan of the context, and they even CSP so that they don’t see yours, browser context wise.
The Point
import process from 'process'; // internally node:process
import pkg from 'pkg'; // internally node:… something that makes this resolve
Can we not say the above is implicit? If in node the default scheme is node: then specifiers are all of that scheme unless they are not.
What about this:
import extendedProcess from '@nodejs/extended-process';
Is it not just like:
import extendedProcess from 'node:@nodejs/extended-process';
Would that not lead to a balance between all things we care about ecosystem wise and still balance with newer notions others are exploring a decade later.
Thoughts?
A while back in #222 and #169 we talked about the idea of having some prefix.
Recent discussions about prefixes have led to a polarizing debate between "prefix" and "namespace" notations — for things that are not necessarily the same thing.
file://…if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs)https://…if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs, and potentially lawsuits)mailto:if the implementation supports the scheme — I don’t think a good implementation wants this to lead to a network request by the browser context itselfIf you have a scheme, it can have zero network-transport and yet an implementation can make it very very meaningful to one loader.
You see this with blobs today — they are memory things — they cannot extend beyond the lifespan of the context, and they even CSP so that they don’t see yours, browser context wise.
The Point
Can we not say the above is implicit? If in node the default scheme is
node:then specifiers are all of that scheme unless they are not.What about this:
Is it not just like:
Would that not lead to a balance between all things we care about ecosystem wise and still balance with newer notions others are exploring a decade later.
Thoughts?