Refactor FunctionClassSpecification

[ccicconetti]

Recap: the FunctionClassSpecification struct is the following:

pub struct FunctionClassSpecification {
    pub function_class_id: String,
    pub function_class_type: String,
    pub function_class_version: String,
    pub function_class_inlude_code: Vec<u8>,
    pub outputs: Vec<String>,
}

Personal view/understanding/comment:

• function_class_id: not used in the code, but it can be used by the system to identify a specific function, together with function_class_version
• function_class_type: used to determine within a multi-run-time agent which runner to use
• function_class_version: not used in the code, but it can be used by the system to identify a specific function, together with function_class_id
• function_class_inlude_code: contains the bytecode of the function, for those run-time for which this makes sense; it needs to be renamed to fix the type inlude/include
• outputs: not used in the code and I cannot see a clear way how it might be used in the future 🤷‍♂️ If that is not correct and we must keep it, then I suggest renaming it as function_outputs for consistency with the other field names

[ccicconetti]

@lukasz-zet does this align with your view?

@raphaelhetzel what do you think?

[raphaelhetzel]

outputs is going to be used for static analysis. It allows the orchestrator / CLI to verify that only existing outputs are used and that all outputs are used. Do not remove that, it will be used later. We can also change that to something like function signature.

class_id, version, and type are required once we have a repository/fetching.

I would assume we will want to keep include around after the repo, obviously without the typo :D

[ccicconetti]

outputs is going to be used for static analysis. It allows the orchestrator / CLI to verify that only existing outputs are used and that all outputs are used. Do not remove that, it will be used later. We can also change that to something like function signature.

OK, let's keep it then.

I think function_outputs is easier to understand than function_signature, since it matches well the output_mapping field in the workflow spec, wdyt?

class_id, version, and type are required once we have a repository/fetching.

Yes, of course.

I would assume we will want to keep include around after the repo, obviously without the typo :D

Yeah. The obvious default is that it will be empty if no code is bundled with the request.