One thing I have frequently thought about with DŌP is how to set up communication channels between Diplomats. The interplay between Diplomats lies at the core of the functionality of an application once protocols have been established. Actions on the Active Axis of one Diplomat are connected to the Passive Axis of another. For example, a Fetch for Diplomat A is also a Request from Diplomat B. Similarly, an Output from Diplomat C would go to an Input to Diplomat D. These connections result in the performance of the actual work being done. How should these connections be made and managed?

My instinct always tells me that it should be done in a way that does not rely on simple CRUD-like operations but offers greater latitude. And while stepping away from CRUD, it also begs to be more discrete and less obvious. I imagine these connections looking more like private exchanges between Diplomats where the instructions for the interaction are sealed in a diplomatic pouch for safe-keeping. The communication channel requires that only a destination be public-facing, like a “To Address” on the pouch. The response simply travels back across the pathway established by the communication itself, like a lightning return stroke.

Thinking about these channels this way makes wonder what mechanism should be used. I often consider the use of a simple POST request/response. When a Diplomat negotiates the work contract, it registers an endpoint for it’s Passive Axis that other Diplomats can use to make Input and Request demands. When the Diplomat needs to make a Fetch or Output demand, it will construct a diplomatic pouch, so to speak, and send the demand to the appropriate Passive Axis endpoint. In this way, Diplomats can be added to an application but not be required to execute code on the Host server. In some sense, Diplomats would all be in the cloud because it would not really matter where the code resides.

Sounds good in theory, but HTTP can be an expensive operation, especially if the code actually does reside locally. The answer, of course, is to design a Diplomat that can do the work of a messenger service. This Diplomat would register the Passive Axis of every Diplomat, including itself, and would act as a go-between for every interaction. Local Diplomats would expose a function call, and remote Diplomats would expose an HTTP/S endpoint for POST requests or even web socket tunnels. The Messenger then accepts pouches from other Diplomats, matches the destination to the receiving Diplomat, and creates the channel to connect the Active Axis of the first to the Passive Axis of the second.

The Messenger would probably be included as part of the core functionality of an implementation of DŌP. But I am certainly getting ahead of myself here. I intend to begin work on fleshing out the format for Work Declarations. Defining Work is the first requirement for building out a proper specification for DŌP. Without it, there’s nothing to negotiate.