Caching for Locker Display

Authors: Jim Taylor, DECE; Peter Davis, Neustar; Joe McCrossan, Fox

The UltraViolet Coordinator is designed to be a central repository of rights and related data, but is not intended to be a remote database for licensee implementations. The Coordinator holds asset metadata, such as summaries or cover art images, ensuring a complete locker view can be shown and providing a convenience to implementers who do not have alternative sources of metadata for all UltraViolet content. However, the Coordinator is not intended nor designed to serve metadata each time a Locker view is generated for a user. Retailers, LASPs, and Access Portals must maintain a local cache of data received for each UltraViolet User that is bound to a local account record.

The Coordinator specification states that API clients should use HTTP cache negotiation strategies (see [DCoord] section 3.9) which means that Nodes should copy Coordinator Resources into local caches. Clients that do not cache Coordinator resources shall be subject to Request Throttling (see [DCoord] section 3.6) to avoid impacting other Nodes. Rights Tokens must not be used for fulfillment without first checking the Coordinator, although Nodes are allowed to service requests from local cache for up to 72 hours since the previous request or if the Coordinator is not available. (See section 4.8 of the Retailer Compliance Rules and section 11.1 of the LASP Compliance Rules [Exhibit A of the license agreement] for details.)

Due to the number of licensees and users per licensee, it is not practical for every instance of a Locker view to pull all data from the Coordinator. The design of the ecosystem requires licensees to distribute the load across their implementations, which more equally apportions the burden. Using a local database provides the added benefit of more sophisticated sorting and filtering than the Coordinator provides. In principle, before showing a Locker view an implementation will ask the Coordinator "Did this User's record change?" If the answer is "no" then display proceeds from the local cache. The result of the request is a lightweight demand on the Coordinator to check status of Rights in an Account, as opposed to downloading hundreds of records worth of metadata, including images, that are identical for assets in other Accounts.

Cache Management

Consider the following potential data updates when managing a cache:

• Locker update
  • Rights Token Create or Delete from the Account
  • Rights Token Update (StreamWebLoc, ALID/CID, discrete media status, etc.)
• User/Account update
  • Username or email update
  • Consent policy update
  • Preferred language update
• Asset update
  • Change to (title, cover art image, ratings, etc.)

For optimal performance, Nodes should maintain an asset (Content) database separate from the User/Account Rights database. This ensures metadata updates apply to a centralized set of asset information instead of being propagated across all Users/Accounts. Asset updates from Content Providers are infrequent and are best handled by periodic background cache checks, bolstered by a dynamic check when an unrecognized CID is encountered.

Note: Nodes are not required to use asset metadata from the Coordinator and may have other sources with different update cycles. However, a Retailer's own catalog of titles will almost surely not match every title in the UltraViolet ecosystem, so a Retailer should supplement its own metadata with Coordinator-sourced metadata for unrecognized content.

Since Rights Tokens could have been added or updated in the interim, Nodes should validate their Rights cache every time a User requests a locker view, at least when the User refreshes the display. If relevant information has been updated, the Rights Tokens should be traversed and updated.

A Recommended Approach

The most effective way to manage a Locker cache is to periodically call RightsLockerDataGet with the response=extreference and onorafter=<date> parameters along with the lastmodifieddate viewfilter. (ETag should not be used in this case.) The Node should then parse through the referenced tokens to remove local copies of any deleted rights tokens and add or update any new or modified rights tokens by calling RightsTokenGet. The Node should record the retrieval date to use as the value of the onorafter parameter on the next call.

An older approach to manage a Locker cache is to use RightsLockerDataGet with the response=extreference or response=reference parameter (see [node:751, "RightsLockerDataGet"] DCoord 7.1.6), .e ETag returned by the Coordinator can be stored and used in subsequent calls. If the locker has not changed, the Coordinator will give a "no change" response. If the Locker has changed, the returned list can be checked against the local cache to see what changed (compare UpdatedDate attribute), what was and what was added, and what was deleted.

Asset metadata updates can be checked as a byproduct of the Rights check. (E.g., if an unrecognized CID is encountered, the Node knows to look it up with a MetadataBasicGet call.)

The outline of the algorithms are as follows:

For Locker cache management:

1. Periodically call RightsLockerDataGet?response=extreference&onorafter=<date>&filterclass=urn:dece:type:viewfilter:lastmodifieddate to see if Rights Token info changed
2. Save the datetime for the onorafter parameter in the next RightsLockerData call
3. If response indicates no change, locker display can begin from local cache
4. Else iterate over Rights Token IDs in the response
   • For each new or updated Rights Token ID, store the data locally (if you need additional info, call RightsTokenGet for details)
   • For each deleted Rights Token ID (as indicated by the status attribute), remove it from the local cache
   • Optionally check each ContentID against your local metadata cache, if no match or if updated, call MetadataBasicGet and update your local metadata cache; if the metadata record has a parent ContentID, traverse the tree to add/update metadata (for seasons, series, etc.)

For asset metadata (ContentID) cache management:

1. Seed your local cache with an initial call to MetadataBasicList()
   • The Coordinator has tens of thousands of titles, so the response will be in pages of 1000 entries (or fewer if you set the page size). See FilterMoreAvailable, FilterOffset, and FilterCount attributes of the view filters (DCoord 3.15).
2. Correlate asset metadata from the Coordinator with any other catalog data and metadata sources using CIDs and/or ALIDs
3. Periodically (perhaps once a day or once a week) callMetadataBasicList() with the lastmodifieddate and onorafter parameters to get a list of all new/changed metadata to add to local cache
   • This assumes that the dynamic check above handles updates that happen between the periodic checks