After we finished merging the first ever openedx events into the edx-platform repo, we are now continuing with the openedx-filters part.
To recap from the previous tread, filters are different than events in that they:
- are edx-platform specific. Most filters are planned for the lms and a few for studio.
- data fed to a filter can be manipulated and returned to the platform for further use.
- execute in a defined order piping the data output from one filter as input to the next filter.
However we still want a lot of the good things that are arriving with events.
- A separate library with definitions that can be used for development and testing without requiring edx-platform.
- A base class for filters that exposes all the tooling and ergonomics.
- Versioning that lets repos evolve in a mostly backwards compatible way.
What we are not so sure of are:
passing OEP-41 envelope information to the filter
Since this is easy to calculate and we could add it in the tooling class. My take here is to leave it and it will help extension developers react better to the backwards compatible additions to a filter signature.
passing actual edx-platform objects to the filters vs using attr objects.
I’m torn about this one. On one hand we could make the filters very stable by passing attr info just as we do on events, but on the other hand we will never anticipate all the possible use cases so we are going to limit the power of extensions to do what they require.
I personally lean towards passing the django objects or regular python dicts so that as an extension developer I’m not restricted to create something at a location where there is already a filter implemented. It’s a double edged sword, because my extensions might break, but it would be my responsibility to use it wisely. This is what is currently at the ADR.
We are working on a PR with all this info written in a more formal way, but I wanted to sum it up in a concise way to see what other might be thinking about this.