First Class Worker Support in Rib

[afsalthaj]

No description provided.

[afsalthaj]

The tickets will be further spliced after a few design decisions. Consider this current description as a pointer to design decisions.

The plan is to be able to write the following (as an example) in Rib

let afsals-instance = instance[acme:foo]("afsals-cart");

let cart = afsals-instance.golem:it/api;

cart.add-item(request.body.item);

This assumes we can parse golem:it/api as a valid "field name" to use when projecting out the cart API from the instance.

This handles the scenario of being able to call the function as part of the main package of the component as well as functions that comes off from other packages.

2 layers of packages

So there are 2 layers of packages, the first one is necessary to identify the component. The second one, to identify the function. In the above example acme:foo is used to identify the component itself, while golem:it/api is the package that has add-item function.

We need to decide on whether we need to translate all : and / as mere dots so that we could write the following

let cart = instance[acme:foo]("afsals-cart").golem.it.api;

Development Steps

• Support parser for parsing function calls with type parameters (in square brackets) in it. Example: instance[acme:foo] will be parsed as Expr::Call(Function("instance"), "acme:foo")

  1. We already have the support of parsing function calls
  2. In this case instance is the function name acme:foo are merely type argument.
  3. Make changes in Rib just to support this aspect as a first step.

• Introduction of modules in Rib, where a module correspond to the main package name of the component. A module will hold all the fields that can be possibly used in the main Rib syntax. This is only an idea, and probably we may need better type safe representation.

struct RibModule {
  package_name: String,
  interfaces: Vec<Interface>
}

• Integrate InstanceType into type inference phases, such that it gets compiled into the currently supported IR.

• We can pre-identify the list of all modules if needed as FunctionTypeRegistry. This implies it can hold Vec<Instance> .Expr::Call(Function("instance"), "acme:foo") will be then inferred as InstanceType which is basically a superset of record type, allowing you to use dot syntax for field names.

instance.golem:it/api

• Every field specification is just similar to selecting a field in a record, however, returns the InstanceType and not the currently used record type. This can only be identified during inference stage.

• To be specific, during inference a Expr::SelectField(Expr::Identifier("instance"), "golem:it/api") will be inferred as InstanceType which we can map with the type registry

• Furthermore cart.add-item(request.body.item) will be parsed as Expr::SelectField("cart", Expr::Call("add-item", vec![...]) which will be inferred as which will be rewritten as Expr::Call(full_function_name, arguments) (the currently supported version, where the full_function_name

[jdegoes]

It could be worth introduce PolyCall with a type argument, rather than pretending that acme:foo is a value argument (it's not, it's really something like a component type)--we can discuss that decision.

Another thing to discuss: how to unify workers with resources. I'd really like to view a worker as a type of resource, so the same mechanism can be used for both.