search

camaraproject / QualityOnDemand

Repository to describe, develop, document and test the QualityOnDemand API family
https://wiki.camaraproject.org/x/zwOeAQ
Apache License 2.0
41 stars 59 forks source link

Clarification: Behaviour when requested duration < minDuration #247

Closed jlurien closed 8 months ago

jlurien commented 9 months ago

Problem description

Question I get from our dev team:

Currently the minimum duration for a session in the spec is just 1 second, but GET /qos-profiles allow to return a minDuration per profile. Behaviour when a value lower than minDuration is requested is not documented.

Possible evolution

Some options I see:

a) Implementation will set duration to minDuration, and return it in the response, in cases when input duration is lower than that value.

b) Implementations will return a 400 error with a dedicated message.

This is kind of scenarios that need to be modeled in the test plan.

hdamker commented 9 months ago

Hi @jlurien ... i suppose you meant in the title "if requested duration < minDuration" and have corrected it accordingly. Said this, the preferred option on our side would be b) (a 400 error with a dedicated message). We plan to set the minimum duration probably to 10 seconds within the profiles.

jlurien commented 9 months ago

Thanks for the title correction. 400 is acceptable here, IMO also.

hdamker commented 8 months ago

@jlurien will you create the PR with the 400 or should I? I would like to have it ready to merge this week, as it should go into v0.10.0 release.

jlurien commented 8 months ago

I can create it

jlurien commented 8 months ago

@hdamker Should I propose the PR for the main branch? do we keep version as 0.10.0-rc or should we upgrade it to 0.10.0-rc2?

hdamker commented 8 months ago

Yes, for main.

In my mind the version is again 0.10.0-wip (= "unreleased"), until we decide and create a new release candidate 0.10.0-rc2 or the final release of 0.10.0. But the first merge after 0.10.0-rc is not already 0.10.0-rc2.

jlurien commented 8 months ago

Yes, for main.

In my mind the version is again 0.10.0-wip (= "unreleased"), until we decide and create a new release candidate 0.10.0-rc2 or the final release of 0.10.0. But the first merge after 0.10.0-rc is not already 0.10.0-rc2.

Ok, that's fine to me