core-service.hpp File Reference

Go to the source code of this file.

Description

Dedicated service node within the UI-Bus to handle command invocation and presentation state.

Mostly, the UI-Bus is just a star shaped network with one central [routing hub][ctrl::Nexus], and serves to distribute generic state and update messages. But there are some special messages which need central processing: The command preparation and invocation messages and the presentation state tracking messages (state marks). The Nexus is configured such as to forward these special messages to the [CoreService] terminal, which invokes the dedicated services.

Lifecycle

CoreService is a PImpl to manage all the technical parts of actual service provision. When it goes down, all services are decommissioned. A part of these lifecycle technicalities is to manage the setup of the UI-Bus main hub, which requires some trickery, since both CoreService and Nexus are mutually interdependent from an operational perspective, since they exchange messages in both directions.

In fact, the CoreService even holds and thus manages the Nexus as a private member, while the latter controls and connects all nodes attached to the bus at runtime, including CoreService. This crisscross arrangement ensures sane start-up and shutdown of the whole UI-Bus compound.

Bus connection and topology

The CoreService plays a central role within the UI, since it represents »the application core« from the UI layer's viewpoint. But it is not the bus manager or central router, a role fulfilled by ctrl::Nexus, the central UI-Bus hub. Every node which has been added into the routing table in Nexus, can be addressed as a first class citizen, that is, we're able to direct messages towards such an element, knowing only it's ID. But there is a twist: all connections to the Bus are made from bus terminals, and each node, i.e. each tangible model element has a BusTerm member and thus inherits the ability to talk to the bus. But only when actively connected to the bus, a full link and entry in the routing table is established. The constructor of model::Tangible indeed makes such a connection right away, while any "free standing" BusTerm just knows how to talk to the Bus upstream, without establishing a full link to receive also downstream messages.

And the fine point to note is that CoreService just incorporates a free standing BusTerm, without registering it with the Nexus. Doing so would be pointless, since CoreService in fact is not a regular Tangible, rather it fulfils a very special purpose within the UI. Most of the UI-Bus messages would not make much sense when directed towards the CoreService. Rather, CoreService acts as upstream for the Nexus, and thus gains the ability to respond to those few special messages, which can not be handled in a generic way on the Nexus:

• act handles command invocation within the Session core, and is treated by forwarding it over the SessionCommand facade to the Steam-Dispatcher
• note observes and captures presentation state note messages, which are to be handled by a central presentation state manager (TODO 1/17).

See also

AbstractTangible_test

BusTerm_test

Definition in file core-service.hpp.

#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/idi/entry-id.hpp"
#include "lib/diff/gen-node.hpp"
#include "include/session-command-facade.h"
#include "stage/ctrl/state-recorder.hpp"
#include "stage/ctrl/bus-term.hpp"
#include "stage/ctrl/nexus.hpp"

Classes
class	CoreService
	Attachment point to »central services« within the UI-Bus. More...

Namespaces
	stage
	Lumiera GTK UI implementation root.
	stage::ctrl
	Backbone of the Lumiera GTK UI.