DOP Diagram

Where Indeed?

One good place to start would be a look at the abstract concept of a “module”. Or in the parlance of DŌP, a Diplomatic Agent or just Diplomat for short. Looking at the model above, you will notice two things. 1) The Passive Axis which signifies Inputs provided to the Diplomat and data Requested from the Diplomat, and 2) the Active Axis which signifies data fetched by the Diplomat and Outputs pushed from the Diplomat. Passive actions are really interactions with the Diplomat. You put something in and pull something out. Active actions are automations performed by the Diplomat. Fetching data from the environment and pushing data out.

How does this work in relation to an application? Consider the idea of a dashboard. A basic place where you could imagine a lot of different modules and plugins that provide functionality. Any plugin or module would fulfill a basic unit of work. This work could be as complex as a calendar with appointments for multiple people, or as simple as a the current outdoor temperature. The function, or work, of the module is described through expectations of interaction, the Input and Request of the Passive Axis. The requirements of the implementation of the module are described through the expectations of automation, the Fetch and Output of the Active Axis. When a module is inserted into the Dashboard using DŌP, these expectations are negotiated by the Host application and the Diplomat. If terms can be agreed upon, the module can begin providing its functionality.

Take the standard concrete example of a To Do List. The work of the To Do List can be represented by four Inputs and three Requests. Here is one way this representation could be defined.

{
    "name" : "To Do List"
    "inputs" : [
        {
            "command" : "create",
            "payload" : ["name"]
        },
        {
            "command" : "done",
            "payload" : ["id"]
        },
        {
            "command" : "not done",
            "payload" : ["id"]
        },
        {
            "command" : "delete",
            "payload" : ["id"],
            "required" : false
        }
    ],
    "requests" : [
        {
            "command" : "all",
            "payload" : ["id", "name", "done"]
        },
        {
            "command" : "done",
            "payload" : ["id", "name", "done"],
            "required" : false
        },
        {
            "command" : "not done",
            "payload" : ["id", "name", "done"],
            "required" : false
        }
    ]
}

The Inputs and Requests have associated commands and expected payloads. These are the defined ways that the Host (or any Negotiating Partner) can interact with the Diplomat providing the service. In turn, the Diplomat would have a representation of exactly what interactions will be provided as well as any requirements it may have. Here is one way this representation could be defined.

{
    "name" : "Forsaken Threads To Do List",
    "work" : "To Do List",
    "inputs" : ["create", "done", "not done"],
    "requests" : ["all"],
    "fetches" : [
        {
            "work" : "Retrieve Persisted Data",
            "type" : "sql"
        }
    ],
    "outputs" : [
        {
            "work" : "Persist Data",
            "type" : "sql"
        },
        {
            "work" : "Update Persisted Data",
            "type" : "sql"
        }
    ]
}

This Diplomatic Agent will perform the To Do List work, but only some of it. You’ll notice it will not respond to the “delete” Input command and only answers the “all” Request command. As these are not required by the Negotiating Partner, it is still possible that a protocol could be agreed upon. Acceptance would rely on whether the Negotiating Partner can fulfill the Fetch and Output requirements of the Diplomat. We see above that it requires the ability to perform a Fetch from a SQL database and to Output data to a SQL database. If the Negotiating Partner can meet these requirements by providing connections with one or more other Diplomats to perform that work, then a protocol can be established.

Where to From Here?

In general, my plan is to create the abstract framework for Protocol Negotiation, Work Declaration, and Diplomatic Agent Declaration. The ideas above provide a basic blueprint for how this might be achieved. I’d like to flesh out this blueprint in the abstract, and then, when ready, prepare an implementation in PHP that can be used and tested. This will likely result in changes to the abstract. In the end, I should have a workable blueprint that could then be adopted for other languages, frameworks, etc.

One of my immediate concerns relates to a visual rendering. I thought about creating a Visual Axis, a rightward and downward diagonal that would have Visual Control Actions coming into the Diplomat, and Visual rendering Actions coming out of the Diplomat. But this really is no different than a Passive Input and Passive Request. A Visual Control Action, say clicking on a Done checkbox, is just a “done” Input command. Getting the HTML markup for a rendering of the To Do List could be a “render” Request command. So, I am not quite sure if a Visual Axis is needed just yet.

This brings me to a key development I hope DŌP can accomplish: compressing the stack. By this I mean reducing the need for separate front and back end stacks. Having the ability to create modules that contain their own pluggable front and back end pieces would relieve a great deal of the double work required to build out an application. I hope that having a mechanism to negotiate modularity will make the process simpler, more well-defined, and easier to achieve. At the very least, I hope that developing DŌP will give me ideas about how to compress the stack some other way.