Emesary

Routing messages between different computers by using an Emesary Bridge layered atop the the FlightGear Multiplayer Protocol The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message. h2.

To take a high level view any system is built from a collection of parts - some of these parts need to perform a required job (the primary purpose) and the parts will need to interface to each other.
The database tier needs a defined API, after all accessing the database is the primary purpose.
This is where a set of classes with methods and properties is required.
During the operation of the database tier it may cause exceptions or failures to be raised. Also the database may need to communicate externally to any number of services that are not necessarily known at build time.

Developing from ground up a new IOS using WPF & C#

C# version of Emesary.

This entire entry is really a set of notes to remind me of an idea I've just had....
There are many ways of implementing an real time executive, i.e. a system that takes responsibility for loading, running, and monitoring individual sections of code.

A technique that I have been using for a very long time to enable the inner workings of code to be cleaner and more decoupled, easier to maintain and extend.

In essence it is nothing that new - event driven systems have been around for a very long time.
What makes this way of doing things different is that it is very lightweight.

There simply isn't an application or software system that wouldn't be improved by having a plugin architecture - but it seems harder to implement.