Navigating the world of distributed systems and plugin-oriented programming often feels like wading through an alphabet soup of terminologies. This feeling is particularly accurate for those delving into idem and Plugin Oriented Programming (POP) ecosystems. As dynamic and innovative tools for managing cloud infrastructures, idem and POP use a unique language to articulate their functions and processes. This blog post aims to demystify these terms, paving the way for a more intuitive understanding of idem and POP.
The Hub
The "hub" serves as the cornerstone of the idem/POP ecosystem, acting as the root of the global namespace passed implicitly to all POP functions. This centralized system eliminates the chaos of circular dependencies, streamlining memory and object management by providing a single point of reference for all functions and variables. This also ensures efficient extendability and replacement of parts of the app, facilitated by contracts and app merging.
Subsystem (Sub)
On the hub, we find subsystems or "subs." Each sub is dedicated to specific purpose, and contains other subs and plugins. Subs also host contracts, which define and control how functions within the subsystem should behave.
Differnt subs can share information through the hub, with global variables and functions defined in plugins available on through their respective reference on the hub.
In the simplest terms, a "sub" is a directory, and a "plugin" is a python file, while a dynamic subsystem is a root-level sub that contains contracts and is intended to be extended by external projects.
Vertical App Merge and Horizontal App Merge
The dynamics between different apps within the idem/POP system is characterized by vertical and horizontal app merges. Vertical app merging allows one app to extend the subsystem of another, while horizontal app merging combines two separate subsystems into one top-level app. Both these processes leverage the inherent flexibility of the idem/POP architecture to create customizable solutions tailored to the user's needs.
Contracts (sig/pre/post/call)
Contracts in POP define how plugins in their parent directory should behave. They come in various forms, such as "signature" or "sig" contracts that enforce that functions exist in a plugin with the right parameters and type hints. There are "pre" contracts that run before the function they wrap to sanitize arguments and perform pre-flight checks, "post" contracts to sanitize or standardize output, and "call" contracts that wrap the calling of a function.
Dunder methods
"Dunder" methods, so-called because of their double underscore wrapping, play a vital role in the idem/POP ecosystem. These include "__init__", "__virtual__", "__func_alias__", "__contracts__", and "__sub_alias__", which each describe how plugins and their functions should be loaded onto the hub and are called when the plugin is loaded onto the hub.
Plugin
In the context of idem/POP, a plugin, or loaded mod, is a component of a sub that contains functions. These plugins are remarkably flexible, with the ability to belong to multiple subsystems simultaneously. A plugin also sometimes refers to a whole POP project that contains no entry-point, only plugins that extend subsystems of another app.
Reference
A "reference" or "ref" is an object's location on the hub. For example, to add a subsystem to the hub you call "hub.pop.sub.add()". The reference to this function is "pop.sub.add".
Contracted Context/Ctx
The "ctx" in a contract refers to the "context." This term is used extensively throughout various POP apps and will be explored in more depth in future posts. In general, it is a namespace that contains context specific to the running of the current function. Contracts use "ctx" in their own specific way, but the "states" and "exec" subsystems from idem use "ctx" in their own unique ways. pop-create also uses it's own version of a "ctx".
DYNE
DYNE is another term to look out for in idem/POP. It is a dictionary defined in a POP project's conf.py file and specifies which folders extend which dynamic subsystems on the hub.
Conclusion
Understanding the specific language of idem/POP is the first step in truly mastering these powerful tools. As you delve deeper into this ecosystem, the complexities of these terminologies will start to unravel, allowing you to leverage the full potential of idem and Plugin Oriented Programming. Our journey through this vocabulary is just the beginning, so stay tuned for more insights into the world of distributed systems and plugin-oriented programming.
Comments