Plugin system

[timofurrer]

There were some Issues and PRs for features which I think should be implement as Plugins/Extensions to twtxt rather then implementing directly in the main code base.

I'd like to collect ideas and proposals about possible interfaces here and discuss about the implementation of some prototypes as a first proof of concept.

[tedder]

I was thinking about using a visitor pattern- it could be done implicitly, but it'd make more sense to have a base extension class that has all of the visitor hooks and simply calls "pass" on them. An extension can choose which ones to implement.

python3 is a little easier in terms of importing a string as a class, which is what makes this pattern work.

[buckket]

I really like what lektor does regarding their plugin system: https://www.getlektor.com/docs/plugins/dev/ https://github.com/lektor/lektor/blob/master/lektor/pluginsystem.py

I’d go for a similar approach, i.e.:

• plugins a separate packages
• they are subclasses of a Plugin class
• we emit hooks, and check if any of the loaded plugins implemented one of those

Only problem I see with this: we would need to pass a context object around so that the plugins can easily modify existing data. The current implementation of twtxt does not really cover this.