search

beakerbrowser / specs

Beaker's specifications [way outdated and inaccurate]
0 stars 1 forks source link

cross origin versioned module cache #2

Open serapath opened 7 years ago

serapath commented 7 years ago

I had a longer discussion on twitter some time ago about web apis and user land. In regular browsers it might be harder to do, but beaker browser natively supports dat so I imagine the following to be feasible. If this is already a well discussed thought that doesn't make sense - then I'm just not familiar with the reasons and would be happy to learn about them.

I'm wondering if its possible to instead of populating the global namespace window with more and more new web apis, to rather add something like require(...) as "the only new web api" in order to require more new web apis similar to how node can require('http') But probably it should be possible to explicitly tell the version someone wants to use, maybe as an additional argument or as a global config file window['package.json'] in order to make the cross origin behavior safe.

In beaker, that would for now probably be:

Those might be built into beaker browser like node has some built in modules BUT: this would enable in the long run, that all those modules could become user land modules (maybe on npm) that use more low level beaker APIs, once they exist. This would enable to remove require('webdb') or require('dat-archive') and when installing Beaker Browser they can instead could come bundled into a cross-origin versioned module cache pre-populated with former web apis as now user land modules (e.g. like require('webdb'), ...)

If beaker browser would even force all those require('...') calls to be async, then - if a module is missing - it could even fetch and populate the module cache on the fly and download missing modules.

That way, adding more and more built-in web apis, like WebDB is completely ok, because they will or might turn into user land modules in the future without spamming the global namespace. Beaker browser itself will then over time probably try to add a minimal core of "beaker system calls" (also using require(...), because maybe in the future there can be an even more minimal core), but deprecated web apis that become user land only could move out of core using the module cache instead.

pfrazee commented 7 years ago

Good topic to bring up!

I was actually discussing this last weekend with a friend. We'll get the opportunity to do something like this via ES modules, which I'm hoping will land in Beaker within a few months. (It depends on when Electron gets updated to Chromium 61.)