feat(client): Add the internal capabilities API (no handshake)

[shane-tomlinson]

Capabilities are a way to query whether the given environment supports
a feature. The goal is to query Firefox to see which FxA features it supports.
With this PR, the signup capability is hard coded, without querying Firefox.

issue #2771

@vladikoff - mind reviewing this to give feedback and see if this is in line with how you were imagining the capabilities API?

[rfk]

A drive-by naming nit, but we should also consider whether "capabilities" is the right term here. For big things like "signup" and "choose-what-to-sync" it fits, but if we use the same mechanism to let the device choose between e.g. halting or continuing to settings, then it doesn't sound like a "capability" so much as a "customization".

[shane-tomlinson]

A drive-by naming nit, but we should also consider whether "capabilities" is the right term here. For big things like "signup" and "choose-what-to-sync" it fits, but if we use the same mechanism to let the device choose between e.g. halting or continuing to settings, then it doesn't sound like a "capability" so much as a "customization".

I'm working on a separate entity for that, for those exact reasons. I'm calling those behaviors.

[shane-tomlinson]

I'm working on a separate entity for that, for those exact reasons. I'm calling those behaviors.

I'm trying to tease these two concepts apart because they feel different. One says what an environment is capable of, the other controls flow. capabilities could be thought of as a subset of behaviors, but at the same time, adding capabilities to behaviors feels like a single muddied concept. Capabilities would be binary, whereas behaviors can hold additional meta information. Maybe behaviors are the only thing that's needed?

[shane-tomlinson]

@rfk - I should start with a problem statement(s) to give context.

All behaviors/capabilities are currently hard coded into the brokers and views. This leads to screen->screen transition control being partly handled in views and partly in brokers. Modifying existing behaviors/capabilities, or adding new screen transitions, or dynamically changing screen transitions requires views, brokers, and sometimes reliers to be updated.

Desired system attributes/behaviors

• A way to define screen->screen transitions and whether features are supported for a particular environment.
• Allow dynamic setting of screen->screen transitions and whether features are supported.
• Logic to define possible screen->screen transitions and feature support should be as self contained as possible. Spreading that logic between views, brokers & reliers is difficult to reason about.
• Views should be relatively unaffected whenever new environments (like Fennec or the upcoming Windows migrator) are supported.

---

Here are a few links to show how I currently think about these two concepts and how they are used. Feedback appreciated.

Capabilities

• Define default capabilities
• Set a capability dynamically
• Query for a capability

Behaviors

• Define default behaviors
• Set a behavior dynamically
• Use a behavior

[shane-tomlinson]

@vladikoff - could I get your thoughts on this? Specifically, whether this API is suitable, or whether there are ideas from your former PR that should be brought over here to bring the APIs into alignment?

[vladikoff]

this is a great start, but it is really simplified. Not sure if that is good or bad. It totally make sense in the refactor but could be problematic for the client integration.

In my case I wanted to make sure that a capability had more distinct names (+ versions) and were also objects that can contain extra details.

[shane-tomlinson]

I'm putting this in the FxA-27 fennec web login milestone because this is for the internal API, not the handshake portion. The internal API will be used to determine whether certain features are supported, e.g., the "open preferences" button.

[shane-tomlinson]

For "behaviors", see #3097

[shane-tomlinson]

@vladikoff and I generated a list of possible data formats at http://oksoclap.com/p/fxa-capabilities. @rfk and I discussed the merits of these and decided on a solution that should allow us to provide the functionality that we need, using a modified version of draft 1:

capabilities: {
  // indicate capability is not supported 
  choose_what_to_sync_web_v1: false, // false could be some other falsy value.

  // for a simple boolean "yep, it's supported"
  choose_what_to_sync_web_v1: true,

  // or, for a more complex case where data is needed:
  choose_what_to_sync_web_v1: {
    customEngines: [
      "bookmarks",
      "passwords"
    ]
  }    
}

When new versions of choose what to sync are needed, a new capability will be created with a new name.

[shane-tomlinson]

@vladikoff - mind a re-review? Can you see #3077 (comment)

[vladikoff]

So this PR is pretty much like last time I reviewed it, Good start!