[REPO-1979] REST API: Add support for IN_PROGRESS in renditions listing Created: 03-Feb-17 Updated: 11-Jun-20
|Fix Version/s:||VB: REST API: V1 Advanced|
|Reporter:||Gavin Cornwell||Assignee:||David Caruana|
|Labels:||ACA, ADF, MediaManagement, triaged|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Epic Link:||REST API - Renditions|
|Comment by David Draper [X] (Inactive) [ 03-Feb-17 ]|
I think that this data should be in the main nodes response (not in the rendition specific API). A client needs to know in a single call for nodes to display whether or not each item (I think this is covered by REPO-1978):
The data should be in the form of map, i.e.
...sensible/better wording should be used
|Comment by Gavin Cornwell [ 06-Feb-17 ]|
Agreed, generally representation are re-used across the API so if the listing response was enhanced with support for IN_PROGRESS then by definition this would be exposed by the include mechanism described in REPO-1978.
Having said that we haven't exposed a listing representation via include before and you're also proposing a different representation be used i.e. a map, I presume that is to make client parsing simpler, thus avoiding iterating through a list and "finding" the rendition you're interested in?
|Comment by David Draper [X] (Inactive) [ 06-Feb-17 ]|
Yes, but I think the requirement is more related to REPO-1978 rather than this one. The requirement of a map is to avoid code like this:
...that is currently necessary to determine what thumbnails are available.
|Comment by Derek Hulley [X] (Inactive) [ 31-Jan-18 ]|
|Comment by Gavin Cornwell [ 01-Feb-18 ]|
Please note that an implementation of handling IN_PROGRESS renditions is already available within the Media Management Module. However, the implementation makes a few low level changes to the action service so it wasn't bought over into core in the first round of recent REST API development.
|Comment by David Caruana [ 02-Feb-18 ]|
Derek Hulley [X] - this issue does not cover REPO-223. We should raise a new ticket to track a failed rendition status (this is currently not done in the repo, there is no apparent persistent location to store a failed status so requires core action service changes).
The comment from Dave re: adding rendition state to node representations is outside the scope of this ticket and should be tracked in REPO-1978.
This can be implemented prior to introducing the platform queue mechanisms by migrating what is already done in the Media management module as the starting step.
A separate ticket should be raised for the Media Management team to remove their implementation of IN_PROGRESS in favour of the ACS 6.0 core implementation when ready. Presumably this would result in a new Media management module for ACS 6.0 onwards. We are not dependent on this, as the existing media management module must continue to run on ACS 6.0, as part of acceptance criteria on this ticket.
|Comment by John Knowles [X] (Inactive) [ 06-Feb-19 ]|
Jan Vonka - does ATS impact this in any way?