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

[pfrazee]

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.

EDIT:
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

[RangerMauve]

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

[pfrazee]

Oh hey, Chrome did this! https://developer.chrome.com/extensions/experimental 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.