You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

At the moment PyAL is used across all the Python based actors (generated via FC2K). PyAL provides another layer between Access Layer and actors.

Current architecture (heavily simplified)

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

  • We can improve the whole solution such way it is based purely on IMAS based Python HLI
  • Once index based (file handler like) exchange  of data workflows will require less time and memory to work - there will be no need of exchanging data back and forth between the calls
  • No labels