The original intent with the separate Interface class was to try and re-use the same interface definition code in the management server, to try and keep everything better synchronised (same with the confdef classes). I suspect this was essentially based on some false assumptions about how the management would work though, and we are now shifting to a "remote node is the source of truth" model, with the server simply as a client rendering config and actions given to it by the remote node.
Without this need to use bits of each module in both the node and the management server, the Interface class can be merged back into the Module class. The dual-stage module setup (initialise all modules, then run a second pass where they can discover and initialise the links and dependencies to each other) can also be simplified. The only part of other modules that really would be good to access in the module ''init'' is hooks, and so their attachment can probably just be deferred. A ''post_setup'' function on the module would probably still be needed for things like starting up background threads or any initialisation that needs interface functions from other modules.
The original intent with the separate Interface class was to try and re-use the same interface definition code in the management server, to try and keep everything better synchronised (same with the confdef classes). I suspect this was essentially based on some false assumptions about how the management would work though, and we are now shifting to a "remote node is the source of truth" model, with the server simply as a client rendering config and actions given to it by the remote node.
Without this need to use bits of each module in both the node and the management server, the Interface class can be merged back into the Module class. The dual-stage module setup (initialise all modules, then run a second pass where they can discover and initialise the links and dependencies to each other) can also be simplified. The only part of other modules that really would be good to access in the module ''__init__'' is hooks, and so their attachment can probably just be deferred. A ''post_setup'' function on the module would probably still be needed for things like starting up background threads or any initialisation that needs interface functions from other modules.
Ideally hooks still get set up and attached in the initial module __init__. While naming and separation of hooks could be up to the user, there could also be a separate management layer to handle that (and we're already namespacing somewhat to find the module and confdef class, based on the filename).
Suggested skeleton:
The hooks could be added via self.addhook("myhookname") and later called with self.hooks.myhookname(). Attach to other modules with self.attachhook("modulename","theirhook",mycallable). The reason this can't be simplenamespaces or something (ie. accessing via attributes) is the attachment usually now needs to be deferred until they actually exist.
Adding interface methods would be: self.addinterface(mythreadsafecallable). Calling interfaces from other modules: self.interfaces.othermodule.othermethod()
Ideally hooks still get set up and attached in the initial module `__init__`. While naming and separation of hooks could be up to the user, there could also be a separate management layer to handle that (and we're already namespacing somewhat to find the module and confdef class, based on the filename).
Suggested skeleton:
The hooks could be added via `self.addhook("myhookname")` and later called with `self.hooks.myhookname()`. Attach to other modules with `self.attachhook("modulename","theirhook",mycallable)`. The reason this can't be simplenamespaces or something (ie. accessing via attributes) is the attachment usually now needs to be deferred until they actually exist.
Adding interface methods would be: `self.addinterface(mythreadsafecallable)`. Calling interfaces from other modules: `self.interfaces.othermodule.othermethod()`
novirium
The original intent with the separate Interface class was to try and re-use the same interface definition code in the management server, to try and keep everything better synchronised (same with the confdef classes). I suspect this was essentially based on some false assumptions about how the management would work though, and we are now shifting to a "remote node is the source of truth" model, with the server simply as a client rendering config and actions given to it by the remote node.
Without this need to use bits of each module in both the node and the management server, the Interface class can be merged back into the Module class. The dual-stage module setup (initialise all modules, then run a second pass where they can discover and initialise the links and dependencies to each other) can also be simplified. The only part of other modules that really would be good to access in the module ''init'' is hooks, and so their attachment can probably just be deferred. A ''post_setup'' function on the module would probably still be needed for things like starting up background threads or any initialisation that needs interface functions from other modules.
Ideally hooks still get set up and attached in the initial module
__init__. While naming and separation of hooks could be up to the user, there could also be a separate management layer to handle that (and we're already namespacing somewhat to find the module and confdef class, based on the filename).Suggested skeleton:
The hooks could be added via
self.addhook("myhookname")and later called withself.hooks.myhookname(). Attach to other modules withself.attachhook("modulename","theirhook",mycallable). The reason this can't be simplenamespaces or something (ie. accessing via attributes) is the attachment usually now needs to be deferred until they actually exist.Adding interface methods would be:
self.addinterface(mythreadsafecallable). Calling interfaces from other modules:self.interfaces.othermodule.othermethod()Attaching hooks should probably check if the deferred init run has already happened, in case people try and attach to hooks later on.