add parameter to Worker Constructor?

[DerThorsten]

Within the worker.ts we import the kernel specific js file (here it is still xeus_lua.js)
https://github.com/jupyterlite/xeus-kernel/blob/ded2690d2a0a706dfa3b7dc2608cf41a5a57429e/src/worker.ts#L3
The question is, can we pass the actual import to the constructor here https://github.com/jupyterlite/xeus-kernel/blob/ded2690d2a0a706dfa3b7dc2608cf41a5a57429e/src/xeus_server_kernel.ts#L20
or do we need to send the import statement as a message to the worker?

I would like to avoid sending the actual import path (like xeus_lua.js / xeus_wren.js) to the worker via message and would prefer if that could be done at construction time of the worker, if possible.

@jtpio any suggestions =)

[jtpio]

One way could have been to use dynamic imports:

const createXeusModule = await import(urlToXeusJsFile);

But looks like it might not work from within a worker on Firefox: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility

[DerThorsten]

But even with dynamic imports, we import the stuff from the worker so we would need to pass urlToXeusJsFile to the worker.
Of course we could do this via postMesage but I would have preferred to pass it somehow via the Worker constructor.

Different suggestion, could we use the same filename for all xeus kernels? The files life in a dedicated folder per extension anyhow, right?

[jtpio]

Different suggestion, could we use the same filename for all xeus kernels? The files life in a dedicated folder per extension anyhow, right?

Yes sounds like it would work? Federated extensions live in their own subfolder indeed, for example:

• /lab/extensions/@jupyterlite/xeus-lua
• /lab/extensions/@jupyterlite/xeus-wren

Would be two different folders but they both can have a file with the same name. Not sure how it would play if we let webpack handle the bundling later (jupyterlite/xeus-lua-kernel#5), but it's probably not something to worry about for now.

[DerThorsten]

The files already have the same name, ie xeus_kernel.{js,wasm}
https://github.com/jupyterlite/xeus-lua-kernel/blob/f53e035f17066388a6052e94ffde68398d2ab7ef/src/worker.ts#L7

So only the Dockerfile building the xeus_kernel.{js,wasm} files differs from kernel to kernel. (and the name / logo of the kernels)

[jtpio]

So only the Dockerfile building the xeus_kernel.{js,wasm} files differs from kernel to kernel. (and the name / logo of the kernels)

👍

[SylvainCorlay]

So only the Dockerfile building the xeus_kernel.{js,wasm} files differs from kernel to kernel. (and the name / logo of the kernels)

👍 exactly what we should get to.

The current content of xeus_server_kernel could essentially be renamed webworker_kernel.js and moved to the JupyterLite code base.

[jtpio]

moved to the JupyterLite code base.

Moved to https://github.com/jupyterlite/xeus-kernel at least as a first step.

There is a chance kernels will be moved out of the main JupyterLite code base (see jupyterlite/jupyterlite#386 for reference), especially since they can be developed as separated federated extensions.

[SylvainCorlay]

The current content of xeus_server_kernel could essentially be renamed webworker_kernel.js and moved to the JupyterLite code base.

Moved to https://github.com/jupyterlite/xeus-kernel at least as a first step.

But presumaby, it is not about xeus, but about any web worker kernel.

[bollwyvl]

I definitely see value in making all the webworker stuff part of a library that doesn't ship to the browser by default in core, but is very easy for a kernel to use. Best of all is if it indeed plays nice with the federated extension system, and only needs loading once. As to normalizing a webworker-based kernel API: I think we could look at comlink, which automates all the postMessage details behind a nice, well-typed async interface. This would even benefit the existing pyolite kernel, the provisioning of which still leaves something to be desired. There's probably some extensions we might want: https://blog.scottlogic.com/2020/04/22/Async-Iterators-Across-Execution-Contexts.html