Duration behavior during session extension

[daniel-dierich]

Problem description
Currently, when extending a session, the additional duration is added on top of the original duration from the session creation. For example when creating a session with a duration of 60s, then waiting for 10s, and extending it for 20s, the new duration is 80s.

Also when currently performing GET /sessions/{sessionId} it is not clear if the duration in the response should be the remaining session duration or the duration the session was created with.

Suggested behavior
The session extension should be added to the remaining time. So creating a session with a duration of 60s, waiting for 10s and extending it for 20s should lead to a new duration of 70s.

In order to provide the values of the original, remaining and extended duration, the duration field at GET /sessions/{sessionId} could be turned into a duration object including the different duration values:

duration: { "original": "60", "extended": "70", "remaining": "50" }

[maxl2287]

I aggree on that point from a developer PoV.
It's unclear for us, if we should update the original "duration" - value (e.g. in this case it's "60") or just the remaining time during extending a session.

Having here an object may also be more clear for the consumer to see, what was the original duration and what is the extended duration.
And of course how many seconds are left. This value changes on every GET /sessions/{sessionId} - request.

[jlurien]

This is also related to the discussion in #280. We have to make clear in the API spec the date-time when the QoS session effectively "startedAt" and when the session is about to expire ("expiresAt"), taking into account the extensions. Then, "session duration" should be the interval between both, and the remaining time is the interval between "now" and "expiresAt". We may discuss if we need to add a new property to save the "requestedDuration" (before any extension).

[hdamker]

Fixed in #296