class NotificationEngine

The notification engine is responsible for generating notifies to subscriber. It is able to find the intersection between

the path interest set of each subscriber with what has changed in the publisher data store and generate tailored notifies

for each subscriber.

To achieve this, the engine tracks data-changes (i.e data dirtiness) at a couple of different levels:

- Per subscriber, per trait instance dirtiness: Every subscriber tracks trait-changes at a per-instance granularity.

Anytime a data source makes known that a property handle within has changed, the NE will iterate over every subscriber

that has subscribed to that trait instance and mark the fact that that instance is now dirty.

- Granular per trait instance, per property handle dirtiness: If selected through compile-time options by the user, the

engine will mark dirtiness down to the property handle. This allows it to generate compact notifies that convey as

succinctly as possible the data that has changed. This will be described in more detail in the solvers section.

At its core, it iterates over every subscription, then every dirty instance within that subscription and tries to gather

and pack as much relevant data as possible into a notify message before sending that to the subscriber. It continues to

do so until it has no more work to do. This could be due to a couple of reasons:

- Notifies are in flight to the subscriber(s)

- We have exceeded the maximum number of notifies that can be flight across all subscribers.

- We have no more space in the packet to stuff in more data.

- We have no more dirty data to process for a particular set of subscriptions.

Once it surmises there is no more work to be done, it returns. If all work for a subscription has been completed, it will

invoke a method in the SubscriptionHandler to finish processing that subscription (which might involve sending out

subscription responses).

During subscription establishment, the NE works slightly differently than at other times - it will retrieve *all* the

data for a particular trait. There-after, it will only retrieve new, changed data.

Some notable features:

- Subscription fairness: The engine round-robins over all subscriptions and will always resume its work loop at the last

subscription it was trying to process to ensure all subscriptions are handled with equal priority.

- Trait instance fairness: Within a subscription, the engine also rounds robins over all trait instances and will resume

its work loop at the last trait instance that was being processed *for that subscription*. This ensures trait instances

that have a high rate of change don't starve out others.

- Inter-trait chunking across multiple notifies: The engine supports splitting trait data over multiple notifies. It will

however only do this split at the trait instance granularity. It cannot chunk up data within a trait.

- Graceful degradation due to resource shortages: If it runs out space in the dirty stores, the engine will degrade

gracefully by generating sub-optimal notify messages that have more data in them while still being protocol correct.