Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beaker "Lab" APIs (a way to keep things moving) #976

pfrazee opened this issue May 1, 2018 · 2 comments

Beaker "Lab" APIs (a way to keep things moving) #976

pfrazee opened this issue May 1, 2018 · 2 comments


Copy link

@pfrazee pfrazee commented May 1, 2018

One of the issues we've been balancing is, how to provide the APIs that apps need without making hasty decisions. For instance, apps very frequently need to seed or unseed dats. We know what such an API would need to do within the current build of beaker, but the library and its policies are still up in the air, so there's a chance the API would need to change later -- breaking apps that depend on it.

The idea I want to consider is a "Lab" concept which let's us introduce APIs that are designed to be temporary. Here's how it would work:

  • We'd create a new toplevel object, such as window.experimental, to house the Lab APIs.
  • Any new "Lab" APIs would be placed there, such as experimental.requestSeed(url).
  • To use such an API, an app would have to opt-in with is dat.json manifest (see below).
    • If opt-in hasnt occurred, the API would throw, explaining which Lab API they need to enable, and providing a link to a page that explains why.
  • The deal would be this: Any Lab API could be disabled at any time. It might happen because there's a new API, or because we realize there's a terrible security issue. As a dev, you accept that risk and know that your app is basically "experimental" too.

The dat.json opt-in would serve three purposes:

  1. It'd be similar to accepting a Terms of Service. It would force a developer to recognize that they're relying on a brittle API, and that their app has a shelf-life as a result.
  2. It'd give Beaker a way to know if an app is likely to break. It can say, "Hey user, this app is using an experimental API that was removed." Also, at a high level, it's able to mark the app as "experimental."
  3. It'd make it possible for us to crawl the dat:// network and analyze Lab API usage.

Here's how the dat.json might work:

  "title": "My app"
  "experimental": {
    "apis": ["dat-seeding", "power-boots", "orbital-cannon"]

APIs would be grouped under identifiers, such as "dat-seeding".

cc @mafintosh @RangerMauve

Copy link

@RangerMauve RangerMauve commented May 2, 2018

I really like the idea of explictly opting into experimental features! This will likely lead to good UX where users will know why a given thing is broken (probably easier to raise issues that way)

What about using vendor prefixes instead of an experimental global?

For example you could have DatArchive.beakerRequestSeed(url), kinda like navigator.webkitGetUserMedia

Copy link
Member Author

@pfrazee pfrazee commented May 2, 2018

Oh hey, Chrome did this! It even has the opt-in mechanism.

Maf gave a +1 in IRC. @RangerMauve yeah I'll think about the vendor prefix, but I feel like we can more strongly communicate that this stuff is in flux with the full experimental global.

@pfrazee pfrazee closed this May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants