Wrapper / Template for non-Typescript models

[pazbardanl]

Prize category

• Best Model
• Best Content
• Beyond Carbon
• Best contribution to the framework

User Story

• As a IF model developer, I want to develop non-TypeScript models starting with a wrapper/template so that I can focus on my custom business logic rather than dealing with the generic / boilerplate stuff.

Rationale

Developers in the community may choose to build models using other languages other than TypeScript. For a given language, the (possibly) many models written have different business logic internally, but they share a lot of common code related to IF interactions:

• SDTIN / SDTOUT handling
• Parsing certain fields in the incoming impl/yml and passing them to the business logic
• Appending the results onto the incoming inputs to create an output block
• Input validation

Impact

If this idea is successfully implemented the creation of non-Typescript models will be significantly faster. Developers will need not worry about handling of input, composing the output and communicating over STDIN/STDOUT. They could focus on their custom business logic and deliver models faster.

Implementation guidelines

• This model MUST conform to the ModelPlugin interface
• This model can be one the following: (1) a template: piece of code with a blank space one needs to fill with their custom model business logic (2) a Wrapper: a ready-to-use library to which one passes a reference to their code. IF shell model calls the wrapper that in turn calls the user's code.
• This model can be in any programming language/tech, although the more commonly used it is the better. https://octoverse.github.com/2022/top-programming-languages
• Hackers are encouraged to: (1) Build more than 1 model (for more than 1 language). Once one is done, the other may take significantly less time to build (2) add in more "frameworky" stuff for consistency such as a unified error message format

Difficulty

• If we provide an example for one the languages: 3/5
• if no example is provided: 4/5

Scope Of Work

• A new model plugin + documentation
• A new feature in an existing model plugin
• A manifest file will have to be written
• Implement test cases
• A new feature to the framework itself (the cli tool)
• It will require changes to the documentation

Examples and resources

Shell model: https://github.com/Green-Software-Foundation/if-models/blob/main/src/lib/shell/README.md

Manifest File

N/A

[jmcook1186]

Hi @pazbardanl - intriguing idea. Can you explain in any more detail why this would be an improvement over our existing ShellModel plugin?

[jawache]

Oh I see. So the boilerplate code you were talking about is boilerplate code for different languages handling standard in and standard out?

If so, totally agree. That'll make everybody's lives a lot easier.

I do think we need to explore a different approach. Currently, the shell model plug-in is instantiated for every single component in a graph separately, which means you call configure and then pass to standard in, and then end the process for every component.

We should explore a way where you start the process when you start running the manifest file and then each component gets passed in as a separate standard in and then there's a protocol where the shell passes something out so that the impact engine knows that it's finished processing without ending the process.

Hope I'm making sense?

[pazbardanl]

"Oh I see. So the boilerplate code you were talking about is boilerplate code for different languages handling standard in and standard out?" -- Yes, but it's not only STDIN/OUT, it's also yml parsing, input validation and output yml handling (and maybe other aspects as well) that are common for all plugins and can (and should, in my view) be decoupled from the business logic.

Regarding the different approach you described:
If I understand correctly the issues (and solutions) we are talking about are 2 separate ones:

(a) Improving development efficiency of "external scripts" (=code to be invoked by the shell plugin) by providing boilerplate code or a wrapper for a handful of selected languages (the more languages hackers tend to the most impressive their submission will be, i can only assume)
(b) Improving the performance of the shell plugin by executing a single instance of it to handle all components, rather than executing it once per component.

if i understand correctly these are 2 separate issues to which the solutions could be developed orthogonally, hence both may be their own hackathon ideas. right?

[jawache]

Correct, it's just that (a) might change depending on (b) but saying that.... we are figuring (b) out in the IF refactor right now so in 2 weeks we'll know for sure.

[pazbardanl]

hey @jawache, @narekhovhannisyan , @jmcook1186
With the design of the new framework now known, i think we may be in a good place to make a decision regarding this.
in my view (a) and (b) could be 2 separate ideas, most likely orthogonal.
let me know what you think.

[NAMRATA-WOKE]

@jawache @jmcook1186 pinging you again to close the loop.