3. Filter tooling: pipeline behaviour#

Status#

Accepted

Context#

Taking into account the design considerations outlined in OEP-50 Hooks extension framework about

  1. The order of execution for multiple functions in a filter must be respected

  2. The result of a previous function must be available to the current one in the form of a pipeline

See openedx/open-edx-proposals#184 for more information.

To do this, we considered three similar approaches for the pipeline implementation:

  1. Unix-like (how unix pipe operator works): the output of the previous function is the input of the next one. For the first function, includes the initial arguments.

  2. Unix-like modified: the output of the previous function is the input of the next one including the initial arguments for all functions.

  3. Accumulative: the output of every (i, …, i-n) function is accumulated using a data structure and fed into the next function i-n+1, including the initial arguments. We draw inspiration from python-social-auth/social-core. See: python-social-auth/social-core

These approaches follow the pipeline pattern and have as main difference what each function receive as input.

It is important to emphasize that the main objectives with this implementation are: to have function interchangeability and to maintain the function signature of a filter defined by the Hooks Extension Framework.

Decision#

We decided to use the accumulative approach as the only pipeline for filters.

Consequences#

  1. The order of execution is maintained.

  2. Given that all pipeline functions will expect the same input arguments, i.e accumulated output plus initial arguments, their signature will stay the same. And for this reason, these functions are interchangeable.

  3. To avoid any mismatch filters must have *args and **kwargs in their function definition.