This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
License expiration is a fairly common concept. Applications could use this information to manage renewals or provide UI to the user. The CDM knows the exact time, which can be based on complex logic. While applications could store this information or retrieve it from the server in most cases, this is not always the case (i.e. offline) and it would be better to expose the exact value the CDM is using. Exposing this information might even address the expired case for MediaKeyError in bug 21798. This could be as simple as adding the following to MediaKeySession: readonly attribute Date expires; For sessions where an expiration time does not apply, the value can be *undefined*. See http://www.w3.org/TR/WebIDL/#idl-Date for additional details on the Date type. Since the CDM is the source of this information, it would need to update the MediaKeySession object if/when it changes. The initial value should be set before createSession()/loadSession() resolve their promise.
I think this is blocked on the discussion about whether session == license. However I agree that this could be useful. I assume this would be based on the local clock?
(In reply to Joe Steele from comment #1) > I think this is blocked on the discussion about whether session == license. I don't think this is blocked. If there were multiple licenses or other expirable items in the session, the CDM could provide an appropriate value based on the combination ("complex logic" in the original proposal). For example, return the soonest expiration time of all licenses > However I agree that this could be useful. I assume this would be based on > the local clock? The time would be UTC, but the current UTC time would need to be based on a local clock.
For the createSession() case, the value will start at *undefined* most of the time and will only resolve to a value after one or more key exchanges. Will the application be expected to poll this value for a change from undefined to a valid date? Or should we add an event to signal this transition, similar to keychanged?
I thought about adding an event, but the use cases seem limited and I didn't want to add more complexity until we're sure we need it. It's not something that is expected to change frequently. For the update() scenario, the promise should be resolved after any related updates are applied. (For the moments) when applications care about other scenarios, it seems polling should work and precise updates are not necessary (as they might be for a change in usable keys)
That's acceptable. I am thinking an application can always poll this on the *keychanged* event in any case, since that is when you will typically find out about expiration. I am ok with moving ahead on this feature. I am assuming any multi-license or non-content license gotchas can be resolved with implementation experience in this case. We may end up with some ambiguity in what this date means, but the negative impact if any should be small.
Implemented in https://dvcs.w3.org/hg/html-media/rev/30b372d9798b