You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.With the above,
start
andstop
attributes of loaded extensions will be captured and executed in order. E.g. pluginA
andB
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.
With the above,
start
attributes of loaded extensions will be captured and executed in order, andstop
attributes would be captured and executed in reverse order. E.g. pluginA
andB
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.The above would collect all
__call__
methods into a signal group namedmiddleware
.Feature flag tracking. Allow extensions to declare
provides
as well asneeds
(hard dependency) oruses
(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
The text was updated successfully, but these errors were encountered: