MagicBus 0.7.3

MagicBus project is an event framework designed to allow developers to concentrate more on developing application components than the means of inter-component communication. MagicBus project strives to enforce the notion of "loose coupling", the lessening of dependency between components that encourages cohesion and reuse.
Present architectures for delivering events between components generally fall into three problematic categories: Direct Access, Internal Event Support, and External Event Support. Examining these categories will help us explain the advantages of using the MagicBus as an event dispatching alternative.
DirectAccess:
With the Direct Access approach components are fairly tightly coupled. If components A and B wish to communicate with component Z they both must maintain a reference to component Z.
Advantages to this form of event communication are that the implementation is simple, easily conceived, and fast for smaller applications. Disadvantages include the necessity of component A to have access to component Z, the difficulty of changing functionality if component Z is altered or replaced, and the problem of correctly multi-threading calls to Z.
Internal Event Support:
Internal Event Support is a common implementation of component communication applied to application components. If component A wishes to communicate with component Z, component A registers as a listener with component Z for component Zs events (or vice-versa). The difference between Direct Access and Internal Event Support is that component Z has an internal delegate (Event Support) that handles the delivery of events to registered listeners.
As an advantage, Internal Event Support limits method dependency by having component A and B register as listeners of Z instead of holding a direct reference. The Internal Event Support also makes it easier to multi-thread calls to Z and from Z to Zs event listeners by implementing custom event support. As a disadvantage, components A and B must either have an ephemeral or indirect relationship with component Z and component Z must have code to implement the delegation for handling ZEvents. Additionally, component Z may have to implement two EventSupport object in order to allow sending and receiving of ZEvents.
External Event Support:
External Event Support is the inverse of Internal Event Support, where the Event Support delegate exists outside the component it supports acting as an intermediary for the delivery and receipt of events. Component A and B register with a ZEventSupport object in order to send and receive ZEvents, while component Z does the same.
Advantages to this method are that component A is decoupled from Z by ZEventSupport. Component Z can change without inhibiting A or B, and Z does not have to include any code for event dispatching. The interposition of ZEventSupport also makes it easier to multi-thread calls to Z and from Z to Zs event listeners.. Disadvantages to this approach center around the fact that Event Support objects generally must be created for each type of event (i.e. XEventSupport for Component X, YEvent, etc...)
Enhancements:
- Support for destroying topics was added.