First Class Worker Support in Rib

[afsalthaj]

[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.

[afsalthaj]

After collating the ideas, the following approach is going to be taken in order to ship the initial version of this feature.

let my-worker = instance[namespace:package/interface@version]("worker name")
my-worker.function(1, 2, 3)

This is with he assumption that Rib knows the component id it is working with. This assumption allows us to release a version of first class worker support with much ease, and will not bump into feasibility issues.

To make things simple further, we could do

let my-worker = instance[interface]("worker name")
my-worker.function(1, 2, 3)

This is because we have the component metadata when compiling and if there is only one exported interface.

Obviously, this could get simplified even further:

let my-worker = instance("worker name")
my-worker.function(1, 2, 3)

This is as if there is only function exported from the component (in all exported interfaces)

The task will be done to solve this problem in version 1.0

[jdegoes]

@afsalthaj

I am okay with the basic approach; however, I think a refinement is needed.

Let's say that in Rib, [...] is used exclusively to disambiguate.

So valid disambiguations would be:

• namespace:package/interface@1.0.0 -- disambiguates between multiple versioned fully-qualified interface names.
• namespace:package -- disambiguates between multiple packages
• namespace:package@1.0.0 -- disambiguates between multiple versioned packages
• etc.

Now, let's assume that the context of a Rib script includes a list of the n dependencies on which it relies, in the form of component identities and min/max version ranges.

Furthermore, let's allow first-class references to whole instances, rather than just parts of an instance.

Then a declaration such as the following:

let worker = instance[namespace:package]("my-worker");

Creates a binding of a component instance to the variable worker. Note that, if the context of the Rib script only includes access to a single dependency (the identity of a component together with ranges), then the disambiguation may be eliminated, because the declaration is wholly unambiguous:

let worker = instance("my-worker"); // You may omit name

If the context of the Rib script includes access to more than one dependency, then disambiguation may or may not be necessary. This depends on how the variable is used -- type inference should support automatic disambiguation whenever possible.

Now, let's talk about calling functions on an instance.

Functions are invoked on instances using dot syntax, like so:

let result = worker.update-profile(request.body);

In the case where a single function of the specified name exists on the instance, then no disambiguation is necessary: the correct fully qualified package and optional interface are inferred automatically.

However, in some cases, a disambiguation may be necessary: for example, there may be a clash between a top-level function name, and a function name inside an interface. Or, there may be a clash between two function names defined in different (exported) packages (separate from the package of the component itself).

In some cases, type inference can determine which function is being invoked, by looking at the number and types of the parameters being passed into the function. In other cases, however, type inference fails to disambiguate.

In such cases, disambiguation must be handled explicitly using [...] notation. However, it is not necessary to specify a fully qualified package name or fully qualified interface name in most cases. Rather, it may be possible to disambiguate with just an interface name. So, for example, if update-profile occurs in interface1 and also interface2 of the same or different packages, then because the interface component of the fully qualified name differs, it is sufficient to disambiguate with just the interface name:

worker.update-profile[interface2](request.body);

Note that the disambiguation occurs after the function name, as with the built-in instance function.

In the worst case, if two different functions occur in two different packages sharing the same interface name, then the disambiguation must contain the full package names:

worker.update-profile[ns2:pkg3](request.body);

In some conceivable case (the same package contains the same function at multiple levels, and also another package contains the same function), it may be necessary to fully qualify the function:

worker.update-profile[ns2:pkg3/inter91](request.body);

In the common case, there will be no need to disambiguate anything:

let worker = instance("my-worker-${request.path.user-id}");
worker.update-profile(request.body)

The parsing rules for the disambiguation syntax [...] would be as follows:

• [<ident>]. This is an interface name, used to disambiguate between functions with identical names across interfaces.
• [<ident>:<ident>]. This is a package, consisting of a namespace component and a package name component. It is used to disambiguate both instances, in case of component ambiguity, and also between functions. Note that version is optional, but if present, would always follow package name (@1.2.2).
• [<ident>:<ident>/<ident>]. This is a fully qualified interface name, used to disambiguate between functions only--and only in the case when multiple functions share the same name and interface (if specified), and differ only in the package. Note that version is optional, but if present, would always follow the interface name (@1.2.2).

[vigoo]

This makes total sense, the only line that first was confusing was this:

let worker = instance("my-worker"); // You may omit name

as "why would we omit the name"? if the answer is that for ephemeral workers, then it is fully clear (but I did not understand it for first as it is not explicitly mentioned).

[jdegoes]

@vigoo Yes, it's for ephemeral workers, or for durable workers if you don't care which worker does the job and you want a new unique worker to perform the work.

[afsalthaj]

Solution: #1324