At the moment PyAL
is used across all the Python
based actors (generated via FC2K
). PyAL
provides another layer between Access Layer
and actors.
Event though current solution works it has some flaws:
1.1.1.1. Template
Python
template (FC2K
) is composed of one, large file that is hard to maintain- Lots of information between components is passed via dictionaries instead of strictly defined interfaces
- Logic of the actor is driven by if-else based approach - it's hard to add new features that are not supported at the moment
- Lots of hidden assumptions are made in the code (e.g. temporary files creation, arguments that are responsible for script execution, etc.)
- Error handling is not quite ideal
1.1.1.2. PyAL module
PyAL module (as a middle layer) seems to be obsolete now. As we plan to push everything towards IMAS based approach it seems reasonable to put PyAL features directly into Python interface, or as an external module that is quite close to Python HLI. At the moment, PyAL is hard to maintain due to:
- parts of code being hardcoded (magic values)
- PyAL serves as yet another level in the whole structure and adds unnecessary complexity to the solution
- It should be possible to implement features of PyAL using features coming purely from Python HLI
- PyAL doesn't support IDS description based data transfer - it means we have to read/write data between calls to native routines
- Changing PyAL is quite hard process. Lots of thing are tangled together via underlaying objects. It means that changing code in one place affects other parts.
1.1.1.3. Workflow
Workflows are the element that will probably require least changes. However it still can be improved.
- Workflows are dependant on
pyal
module andimas
module.