Buffered and Relayed ContextEvents (maybe ServiceRequests and UIRequests too)

[saiedt]

In my opinion, the context bus must introduce new concepts to support not only "real time" events but also buffered and replayed events. In order to keep backward compatibility it may introduce AbstractContextEvent as the superclass of the current ContextEvent and add two other subclasses of AbstractContextEvent, probably called BufferedContextEvent and ReplayedContextEvent.

Explanation 1 - Why "BufferedContextEvent": I think that we need it for scenarios when due to connectivity problems a uSpace loses its coherence and e.g. is split into two disconnected sub-spaces (we had this case during ReAAL in the EIC-IL pilot); in that case, context events published in one sub-space may be buffered and published on the other sub-space after the sub-spaces are joined again. In my opinion, the context bus would need to consult the CHE for all buffered context events whether the data has been already overwritten by a newer context event or not before deciding if and how a buffered context event is published. During the "consultation phase" CHE should make sure that the buffered context event is stored in the managed history of context events.

Explanation 2 - Why "ReplayedContextEvent": Recently, a student of mine wanted to write a service component that replays all happenings in a uSpace from a given interval in the past:

query the CHE for all context events within that interval, sort them by timestamp and then visualize the happenings with the same "speed" as the events were originally published; the visualization is being done in a Web-App that uses the replay servcie remotely via REST API

I think that the best component to implement the underlying replay service (determine the list of context events to republish in the right order and with delays between two subsequent events as it was in reality in the past) is the CHE, but independently from that, the question arises is whether CHE (or whichever component that realizes this service) should create a parallel eventing mechanism for this purpose to which the users of the replay service will have to subscribe, or it would be better if the context bus supports the related eventing. In my opinion, the second option is the better one even if I don't know if there will be any other components interested in replayed context events, In any case, applications like ours that wants to visualize the happenings captured by these context events should then subscribe to this kind of events only, and "handle" the received context events only if they are within the interval it wanted (to make sure that possible parallel replays do not intervene).

[Alfiva]

I see the usefulness of Buffered, but I think Replayed is something more at the application level. I don't think it's a feature we need at platform level.

[amedranogil]

Once ContextEvent is "semantized" (see https://github.com/universAAL/ontology/issues/8 ) applications could create these kind of specifities for ContextEvents, going as far as defining other subclases for scenarios we haven't concieved yet.

Said that I do see the potential of BufferedContextEvent for the latests features of the MTGW; which actually implement the scenario you describe, transparently for applications (in addition to buffering BEFORE the first connection; which is another scenario from an implementation standpoint).

These MTGW features also implement ServiceRequest buffering, they are configured at MTGW level, rendering timeout after the configured time without connection & response. But I do see scenarios where some requests need to be more time sensitive, where others could wait longer; which means a similar concept can be added to ServiceRequests to allow Applications to specify the time restrictions (and other lower level properties) for each ServiceRequest