Comments (7)
Decision from QoD Call March 22nd:
- Option (b) will be followed, update of documentation as described in issue
- In addition the limit of duration has to be eliminated in SessionInfo => reference to "CreateSession" has to be expanded to allow that
- The PR for this issue will be included within the v0.10.1 patch release
Action:
- PR to be created - @emil-cheung
from qualityondemand.
@emil-cheung Currently the description you have cited does not allow to extend beyond the "maximum limit" which is defined as 86400 seconds in SessionInfo
:
The remaining duration plus the requested additional duration shall not exceed the maximum limit. Otherwise, the new remaining duration will be the maximum limit.
But there is another reason to remove the "86400 seconds" limit from SessionInfo
, see #249. The maxDuration
will be given by the QosProfile going forward (currently we have restricted maxDuration
with a comment in the description also to 86400 seconds, to avoid inconsistencies). maxDuration
will be then the upper limit for a session duration and "extend session duration" shall not allow to extend beyond this limit.
Do you agree to close your issue and continue the discussion within #249?
from qualityondemand.
@emil-cheung Currently the description you have cited does not allow to extend beyond the "maximum limit" which is defined as 86400 seconds in
SessionInfo
:The remaining duration plus the requested additional duration shall not exceed the maximum limit. Otherwise, the new remaining duration will be the maximum limit.
But there is another reason to remove the "86400 seconds" limit from
SessionInfo
, see #249. ThemaxDuration
will be given by the QosProfile going forward (currently we have restrictedmaxDuration
with a comment in the description also to 86400 seconds, to avoid inconsistencies).maxDuration
will be then the upper limit for a session duration and "extend session duration" shall not allow to extend beyond this limit.Do you agree to close your issue and continue the discussion within #249?
@hdamker
Probably a bit more discussion before closing the issue.
Let's take one step back to clarify our understandings.
Please allow me to describe an extreme example.
Let's say a developer originally created a QoD session with duration of 86,400 seconds (already reaching the max limit).
Now, 80,000 seconds has passed and he wants to extend the duration with another 80,000 seconds.
At this very moment:
- Elapsed time is 80,000 (s)
- Remaining duration is 86,400 - 80,000 = 6,400 (s)
- Requested additional duration is 80,000 (s)
- Remaining duration + requested additional duration is 6,400 + 80,000 = 86,400 (s), which is still within the max limit.
- Total duration is 86,400 + 80,000 = 166,400 (s), which significantly exceeds the max limit of 86,400.
My understanding was that as remaining duration + requested additional duration is 86,400 seconds, the duration extension request is acceptable. While your understanding is that since total duration is 166,400 seconds, the duration extension request is not acceptable.
I am fine with either understanding, but let's clarify which one is the expected one among the community.
If my understanding is correct, then the max limit in 'SessionInfo' should be removed;
If your understanding is correct, then the API documentation should be improved, e.g., adding additional statement about the total duration shall not exceed the max limit.
from qualityondemand.
Hi @emil-cheung and @hdamker,
Upon thorough review, it appears that the following formulation may be ambiguous and thus requires adjustment:
... (1) the new duration of the target session will be the original duration plus the additional duration.
(2) The remaining duration plus the requested additional duration shall not exceed the maximum limit. Otherwise, the new remaining duration will be the maximum limit.
Paragraph 1: In this section, the new duration of the target session is the sum of the original duration and the additional duration.
Paragraph 2: Here, the new duration time is the sum of the remaining duration of the session along with the requested additional duration.
In the handling of session information, (SessionInfo),
parameters such as "startedAt"
and "expiredAt"
are crucial. To ensure that the duration limit of a session does not exceed beyond a day, I propose integrating the logic from the first paragraph. An example of extending a session could be as follows:
var newDuration = oldDuration + additionalDuration;
var newExpiresAt = oldStartedAt + oldDuration + additionalDuration;
..
if (newDuration > SECONDS_PER_DAY) {
newDuration = SECONDS_PER_DAY;
newExpiresAt = oldStartedAt + SECONDS_PER_DAY;
}
The limitation of a session to one day would be maintained.
The second paragraph appears to lack coherence, as it would imply extending the duration of a session beyond a day.
I trust these adjustments better align with the basic requirements.
from qualityondemand.
@dfischer-tech I agree, the second paragraph is ambiguous. We might have had another semantic in mind when writing it.
There are two options:
(a) maxDuration (or the limit of 86400 seconds) is absolut. Also the extended session duration can't be beyond this limit.
(b) maxDuration is relative to the current time. The maxDuration will be "restarted" by extendDuration (similar to deleting the current session and creating a new one). The requirement would be in this option that "expiresAt" is not more than maxDuration into the future.
We had defined the calculation of the new duration based on the original duration (the first sentence), to avoid unclarity about the new duration.
Regarding the limit for the duration we obviously currently described the option (b). The new remaining duration shall not exceed maxDuration. But as @emil-cheung has rightfully shown, that would mean that the resulting overall duration of the session could exceed "maxDuration" (even could be unlimited extended again).
If option (a) we need to correct the second paragraph, e.g. to
The resulting duration shall not exceed the maximum duration limit. Otherwise, the new session duration will be set to the maximum duration.
If option (b) we need also make the second paragraph clearer:
The *new* remaining duration shall not exceed the maximum duration limit. Otherwise, the new remaining duration will be set to the maximum limit. The remaining duration is calculated as the 'expiresAt' minus the current time of the extendDuration API call
We need also to add examples to make it clear.
We have to decide first if we want to follow option (a) or (b). and then patch the documentation.
@emil-cheung @jlurien @eric-murray @SyeddR @RandyLevensalor - which option is fitting to your understanding and should be followed?
from qualityondemand.
(b) maxDuration is relative to the current time. The maxDuration will be "restarted" by extendDuration (similar to deleting the current session and creating a new one). The requirement would be in this option that "expiresAt" is not more than maxDuration into the future.
@hdamker I'd lean towards option b.
By treating extend duration as a new session, we can apply the same pending / approval flow as we would for a new session. We also need to ensure that we document the behavior if the session can't be extended. This also allows a service provider to implement a policy that would reject an extend session that exceeds the maxDuration of the initial session in their business logic without limiting their options.
Also, with treating extend session as new session it keeps the door open to allow for other QoD session attributes to be changed in the same manner. Either through a patch or a specific modify option, such as we are using with extend session.
from qualityondemand.
My understanding on the topic was also option (b), but I see the ambiguity in the statement. Option (b) allows more flexibility and it's probably easier to understand for developers. We may discuss if implementations could impose further limits to extension. It's somehow related to #257
from qualityondemand.
Related Issues (20)
- Adding `notificationUrl` as an optional property in `CloudEvents` HOT 1
- Return 422 instead of 501 if the service is not implemented for specified device
- Align error responses for Device Object with v0.4.0 of Design Guidelines HOT 1
- Application IPs are not shared by OTT for QOD API HOT 4
- Updating API Readiness Checklist(s) with new template
- Remove unresolved reference within quality-on-demand documentation
- Remove cucumber code from the repository HOT 1
- Device in response object need to be omitted or clearer defined HOT 3
- Fill API Readiness Cheklist for qod-provisioning
- Alignment of notification web hook to CloudEvent subscription model HOT 1
- Update reference to the QoS Profiles API HOT 2
- Prepare release PR for r1.1
- Potential enhancement of booking feature for qod-provision HOT 1
- Remove reference to protocol in sink description HOT 3
- Mentioning of the device object in the Session Info description
- Add user story for QoS Profile
- Review and update User Story for Quality On Demand
- Quality on Demand example RETRIEVE_SESSIONS_EXAMPLE must use sink HOT 2
- Operation to get qos-profiles for a device MUST use a verb and needs a security object HOT 2
- Info "The developer can optionally specify the duration" is wrong
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qualityondemand.