(b) Context aggregation — Applies the aggregability function to every incoming context message, providing both the sender and recipient's contexts.
Radiator does not assume a specific kind of matching — it is up to the developer to implement the aggregability function (responsible for matching and aggregating) using the most appropriate techniques for his specific needs.
Let C S be the current context of sender S and C R the current context of receiver R. The aggregability function G(C S,C R ) represents how much aggregated the message must be before being transmitted to R, taking into consideration both C S and C R. G returns a tuple in the following format: G ( C S, C R ) → { type : value }, type ∈ ( volume, time, people ).
Depending on the aggregability function, the server may decide to propagate the message immediately or aggregate it with other messages.
This effectively represents (possibly with some delay) the current context of each client, which is used by the aggregability function to decide its result.
Moreover, the propagation path is completely dynamic: the set of recipients of each message is continuously changing based on the result of the aggregability function.
Then, this list is iterated (from the oldest to the newest) while the aggregability function is applied to each pending message (line 7).
This is done using the variable pending _queues, which stores every result of the aggregability function along with the corresponding list of messages (line 8).
In addition, the result of the aggregability function may vary with each message in the pending list, so we have to group them by result.
Every client will eventually receive all context messages but, depending on the aggregability function, some may receive the messages sooner than others.
