Skip to content

Generalize WebCore additions and improvements. #5

@amcgregor

Description

@amcgregor

WebCore utilizes marrow.package extensively for plugin/extension services and has developed a useful abstraction for the collection of named extension callbacks; essentially protocol methods of the extension objects which itself has a protocol to advertise new callbacks to collect. (Allowing an extension to define callbacks for its own use, not just as defined by the host application.)

Protocol components to port:

ExtensionManager

  • Declaration of SIGNALS; a set of attribute names to collect. E.g.

     SIGNALS = {'start', 'stop'}

    With the above, start and stop attributes of loaded extensions will be captured and executed in order. E.g. plugin A and B would have their callbacks executed: A.start, B.start, A.stop, B.stop.

  • Allowance for declaration of callback ordering by prefixing the attribute name with a minus. E.g.

     SIGNALS = {'start', '-stop'}

    With the above, start attributes of loaded extensions will be captured and executed in order, and stop attributes would be captured and executed in reverse order. E.g. plugin A and B would have their callbacks executed: A.start, B.start, B.stop, A.stop. This allows for easier simulation of "middleware" behaviour.

  • Allowance for re-naming / aliasing callbacks to be gathered. A SIGNAL entry may either be a string literal naming the attribute to collect and naming the collection of those callbacks, or a tuple naming the group and attribute origin independently. E.g.

     SIGNALS = {('middleware', '__call__')}

    The above would collect all __call__ methods into a signal group named middleware.

  • Feature flag tracking. Allow extensions to declare provides as well as needs (hard dependency) or uses (optional dependency) sets. These are generally free-form string identifiers defined by the application hosting plugins.

  • Utilize the topological sort of extensions based on provides/needs/uses tag-based associations. Due to the inherently ordered nature of the callbacks being collected, collection (and execution) is dependent on explicit ordering, or implied ordering through dependency resolution.

For details on the WebCore implementation, see: https://github.com/marrow/WebCore/blob/develop/web/core/extension.py

For an example outlining WebCore's complete extension API, see: https://github.com/marrow/WebCore/blob/develop/example/extension.py

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions