Kits rev 3

tl;dr: Kits as we know it are dead. Long live BGL files.

Fundamentals

• There are two kinds of boards: declarative and imperative

  • declarative boards are ye olde graphs
    • can be main graphs or sub-graphs
      • main graph is at the root of BGL file
        • URL of main graph = URL of BGL file
      • sub-graph is a key (aka subGraphId) in the “graphs” property bag
        • URL of sub-graph = URL of BGL file + “#${subGraphId}”
  • imperative boards are graphs that have the “main” property set
    • the “main” property points to a module within the respective BGL file that will provide both describe and invoke bits of a graph
    • modules are items in the BGL file’s “modules” property bag, each key is moduleId
    • the URL of a module = URL of BGL file + “#module:${moduleId}

• A the bottom, there are capabilities: fetch, invoke, secrets, input, output

  • You build boards by composing capabilities and other boards
    • board = [capability]* + [board]*
  • We will add more capabilities as we start needing them, but we expect the number to be very small. This is the Breadboard Bedrock.

• Only some capabilities are accessible from modules

  • Currently, it’s fetch, invoke, secrets
  • We may introduce input and output eventually

• Components are entries in the BGL “nodes” array, with the “type” property specifying either:

  • the URL of the board
  • the name of the capability

• Thus, most of the components are boards.

  • capabilities are intentionally verbose and sharp-edged. They are designed to be low-level.

• The BGL file contains boards and modules

  • and later, assets – bits of content that you can choose to store alongside the boards and modules.
  • A BGL file defines a “Workspace”: a single place where you can build something useful.
  • A BGL file can export more than one board
    • The “exports” property array specifies the board IDs that the BGL file deems as distributable – in addition to the main graph, which is a sort of default export.

• A BGL file that has more than one export is called a “Kit”

  • Kit is an organizing concept. Example: Google Drive Kit contains a collection of exported boards designed for working with Google Drive.
  • Maybe we don’t even have the word “Kit” in Breadboard vocabulary anymore. It’s just a Workspace with multiple exports.

Reconciling the past

• RunModule

  • RunModule is just an component with a module URL as type

• Invoke capability component

  • we will need the “invoke” capability component, distinct from components with URL as type, similar to how there are import declarations and dynamic import() in JS.

• Kits

  • Looking at at the fundamentals, we can imagine that the old-style Kits were a kind of type-aliasing abstraction:
    • type of a node = alias to board URL
    • “promptTemplate” is actually “url://of.promptTemplate/board”
  • We will eventually remove this type aliasing abstraction altogether, but for now, that’s how we’ll treat it.

• For all components that currently live in Kits

  • “fetch”, “invoke”, “secrets”, “input”, and “output” become capabilities.
    • We can even present them as “Capabilities” pseudo-BGL, for organizing purposes
  • all other components become boards, each hosted in the respective BGL named the same as the old-style Kit.

Looking to the future

• Component selector and board list are two views on the same data

  • They could be conceptually the same thing, we just need a powerful flexible selector to filter, group, and sort.
    • Let’s call it “Unified Board Picker System” (UBPS, pronounced “oops” and named after a song by a famous pop singer)
  • Component selector is
    • list all boards that have “component” tag
    • group by BGL file that they came from
    • group remaining group-less boards by board server
    • sort by name (need it to be stable)
  • Board list
    • list all boards that have “published” tags or are mine
    • add “last recently used” group
    • group remaining by Board Server
  • Tool picker is also a view on the same data
    • list all boards that have “tool” and “published” tag or are mine
    • group by Board Server
  • We can now imagine custom views.
    • model picker
      • list all boards that have “model” tag
      • sort by last recently used, etc.
    • agent team picker
      • list all boards that have “agent” tag
      • etc.

• Dragging, dropping, picking boards

  • Dragging a board from the unified board picker or workspace view creates a new component
  • Dragging it onto a behaviors: [“board”] input port creates a reference (aka Floaty Boi 🛟)
  • The board picker in node configuration (triggered by behaviors: [“board”] on the input port) becomes a drop target, accepting items from unified board picker
    • Need a way to type in/paste arbitrary Board URLs as well

• Less formed

  • The unified board picker is reactive maybe? Changes the view based on the context
    • when opening the node configuration with a board input port, changes to “[X] picker”, where [X] is a list of tags provided by the input port?
      • “tool picker” -> behaviors: [“board”], format: “tool”
      • “model picker” -> behaviors: [“board”], format: “model”
      • “team picker” -> behaviors: [“board”], format: “team”
      • ...