Proposal: None network related Url Specifier Handling

[frank-dspeed]

Enable Direct referencing browser components via url specifers

Proposal: consider url parsing to be more flexible about colons in the protocol part of a url enabled Dynamic -extension:// protocol resolved via serviceWorker

we can also name this:

• Component based url specifiers
• none network related extension specifiers
• dynamic extension url handling extension://
• dynamic url registration

Proposal

Currently Fails

new URL("[email protected]:/me") // Fails

Expected

new URL("[email protected]:/me") 

{
  protocol: '[email protected]',
  path: 'me'
}

<protocol ends with : >:<pathHashSearch>
/*
for compat if path starts with // and protocol is http<s> we strip it from path and 
take the domain and port as done before but if the protocol is unknown we strip into protocol path and path it to the serviceWorker or what ever implements the fetch load of the ECMAScript tc39 Spec
*/

fetch should use the ECMAScript resolve and loader implementations

so this is related to URL Object in tc39 and whatwg fetch and maybe whatwg url definition.

Why?

Browsers get more modular and even build custom for embedded devices this is at present complicated so the WinterCG got created to address needs of Web Interoperable Runtimes the most famouse of that runtimes is maybe Chromium or Webkit depends on the view. Both projects get now split into internal IPC Connected Components. it solves as referenced in the issue the problem of assertions that are not based on a file extension or a additional meta like

import me from '[email protected]:whatwg/fetch'
// and not
import me from 'whatwg/fetch'  assert { type: "git+ssh@github" };

so it would be url serializeable

this is used in bundlers and runtimes already

import fs from 'node:fs'

i want to turn url into a specifier resolve algo for better interop on the long run with other browser external or internal components as we overall design browser more modular today

now as a coder and web author it would be beneficial if he could define ways to interact with them directly from the dom in a declarativ way without coding additional web components. As also existing interop between url specifiers in NodeJS and Browsers is not given as new URL does not handle none http related urls well.

use cases

Accessing Components

fetch needs to be enabled for example to accept raw graphics pipeline input which it is able to do at present i am passing a memory fileDescriptor to it and stream the body but at present i bound that in a hardcoded way and all other components do so

it would be beneficial if we could fetch raw body streams and post to them directly via a unified url protocol

this would even enable circumventing the ECMAScript context. internal

this also enables a whole set of stuff that we transpil at present before the run

<!-- Current snapshot of the webgpu rendering result at time the element got inserted into the dom -->
<!-- directly copyed internal no round trips direct mem copy -->
<img src="webgpu:0">

• It will supply the fundamentals for linking the components cake layer into the dom via url specifiers
• think about it as a dynamic unified version of the extensions:// protocol implemented in browsers

WinterOP

does enable again interop without transpilation with other ECMAScript Runtimes that are Web Inter Operable

see:
see:

• v16.18.0 breaks npm ci nodejs/node#44998 (comment)

so what i vote for is that we get it some how into any standard that is Winterop related that fetch should accept more then one : while taking only the last as protocol specifier

'me+go@da:lo.//mego' + '://me'
URL({
  protocol: 'me+go@da:lo.//mego',
  path: 'me'
})

as i think more about all the possible combinations with ports this needs some refinement it is not the only rule to take the last ":// " maybe some more rules are needed like if there are more then one double point. Bit i guess you all get why we need that
custom protocol specifiers are one of the most best interop features today to get the browser and other runtimes into diffrent handling.

the only alternate to custom protocol specifiers are searchParms and URL Hash which are by fare less readable then protocol specifiers like

import('ts:my-typescript')
import('npm:my-module')
import('local+json:my-module')

vs

import('my-typescript#ts')
import('my-typescript?ts=true')
import('my-module#npm')
import('my-module#local+json')

Allows implementation of custom protocol handlers

This enables dynamic protocol handler registration on the serviceWorker level which resolves the fetch requests.

[annevk]

I'm sorry, but I don't understand this. Perhaps this can help with writing a clearer issue: https://whatwg.org/faq#adding-new-features.

[valenting]

Expected

new URL("[email protected]:/me") 

{
  protocol: '[email protected]',
  path: 'me'
}

Why would you want it to parse like that? You usually want a hostname from the URL. In any case @ is not a character allowed in the protocol part of the URL.

[frank-dspeed]

@valenting see updated proosal above

[annevk]

I recommend trying to work with the Winter CG into turning this into a more actionable issue. As-is I don't really know what this is asking for and if this is about URL parsing that's not something that Fetch can change.

[frank-dspeed]

@annevk who changes url parsing?