how do relative URLs work?

[wanderview]

A lot of algorithms implicitly extract the current base URL out of the current settings object. For example, fetch() with a relative URL does it in step 4 here:

https://fetch.spec.whatwg.org/#dom-request

How do all these algorithm references to "current settings object" work in a "block"? This seems somewhat related to selecting a global as covered in issue #1. But beyond that, what is the base URL of a Worker running a "block"?

[domenic]

Have you looked at the sample code for implementing worker()? That should answer the question pretty well.

[wanderview]

If that is a library, then yes. If the browser is implementing it, though, then it's not clear what the worker URL is. Unless we standardize block-receiver.js, etc.

Also, I guess I was thinking you wanted to pass a block as the worker script itself. If you are saying a block cannot be used to create a client directly, then I agree it simplifies things.

[domenic]

The way I envision it, the browser's worker() would be very similar to the one shown there, except it probably would use a worklet, whose base URL gets set to the current settings object's API base URL. But that's all implementation details of the browser's worker(), and not related to the syntax proposal here, which just provides a general framework for opaque function handles that can be transfered and later reified.

[wanderview]

On first read of this proposal I really expected this to be a more ergonomic replacement for data/blob URL workers. It seems like a missed opportunity not to make that work. It also seems not too hard to say that passing a block to new Worker() would effectively do the equivalent of serializing to a blob and executing the blob URL worker. That would get all the implicit inheritance of origin, service worker controller, etc.

[domenic]

Sure, that's another way one could implement worker(), I imagine. Once you have the general tools of this proposal (the ability to serialize, transfer, and reify code) you can propose anything you like for the web platform side.

Once we have some assurance that TC39 is interested in changing the language syntax at all, it might be time to start thinking about the web API side.