Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize WebCore additions and improvements. #5

Open
amcgregor opened this issue Dec 11, 2018 · 0 comments
Open

Generalize WebCore additions and improvements. #5

amcgregor opened this issue Dec 11, 2018 · 0 comments
Assignees

Comments

@amcgregor
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant