[CDS API] Per media type update ids to allow clients to effectively cache responses

[Will Lunniss]

This ticket proposes a simple system which will go some way towards allowing CDS clients to minimise the number of refreshes needed, while keeping content up to date for users.

Each response to a browse request should return a meida type specific (audio, image, video) update id that changes whenever a file of that type is:

• Added to the library
• Updated in the library
• Removed from the library

These update ids could be delivered either in the ETag, or as part of the response itself.

The following top level categories should not affect the update id.

• Any online content
• Random categories
• Last accessed e.g. Last Listened and Last Viewed

This means a client only needs to re-fetch the top Audio, Image and Video containers on demand to determine if any the cached data is still valid, or if it needs updating.

[Will Lunniss]

Any chance of getting this into 1.4? Even in this simple form of one id per media type, it should allow me to make a noticable improvement.

[Petr Nejedly]

i will mark it for 1.4, but will see if I can get it in. i'm constrained by time to get 1.4 out before i go on honeymoon ;-)

[Will Lunniss]

Thanks, I guess that’s a valid excuse :-D

[Petr Nejedly]

added a non-persistent cache (per file type).