[Bug 16738] Provide more guidance on heartbeat implementation

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16738

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #2 from Mark Watson <watsonm@netflix.com> 2012-05-30 22:17:43 UTC ---
(In reply to comment #1)
> In option 1, keymessage would be used to provide the heartbeat, which must be
> ACK'd by the server. The thought is that this ACK would be provided via
> addKey().
> 
> While this option seems more sensible for the server and CDM, it is not
> consistent with normal uses of addKey() (and the pairing with
> generateKeyRequest()). Is there a better name for addKey() that addresses both
> use cases? (Assuming we make the change in bug 16548) addKey() is always a
> response to a keymessage event, though one could imagine multiple addKey()
> calls for a given message.)
> 
> 
> Option 2 is very consistent with the initial key request, but seems overly
> complex for a periodic heartbeat related to the same license.
> 
> 
> The current text says an "an expiration time or valid duration" should be
> provided in the license. This language seems specific to option 2 and should be
> changed if we choose option 1.

I prefer Option 1 as it does not require much special knowledge in the script
about heartbeat. When it gets a keymessage from the CDM the script just does
what it usually does (send that to the server, get the response and give the
response to the CDM with addKey).

addKey is not such a bad name: heartbeat can just be thought of as a sequence
of expiring keys.

A more generic name would be ok, but making it as generic as "provideMessage"
would be too much - we should retain the semantics that what this method does
is provide data that is needed to (continue) decrypting the content.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 30 May 2012 22:17:46 UTC