[Bug 24081] The READY state is too limiting and should be more like the PENDING state

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|LATER                       |---
            Summary|There may be use cases for  |The READY state is too
                   |calling update() in states  |limiting and should be more
                   |other than PENDING          |like the PENDING state

--- Comment #2 from David Dorwin <ddorwin@google.com> ---
Note: The original bug report was "There may be use cases for calling update()
in states other than PENDING". I've changed the summary to cover the general
problem. Also, I don't currently have a use case for calling update() in ERROR
or CLOSED.


There are other (more likely) cases where the requirement that (paraphrasing)
"a message event must put the MediaKeySession in the PENDING state and update()
may only be called in pending" is problematic.

Consider the renewal request case where the following occurs during playback:
 1. The CDM fires a message event to request renewal.
 2. As a result, the state must go to PENDING - even though the session is
still valid/"READY" and continues to be usable.
 3. The application replies with a renewal: update() causes the state to return
to READY.

Should a valid/usable session remain in PENDING just because it sent a message
or might expect a message? Technically, it probably doesn't matter since
PENDING is just a superset of READY (see below), but it could be
confusing/unexpected. Also, while we might expect to return receive a response
within a few seconds and return to the READY state, this may not happen when
offline (something the CDM cannot detect).


Stepping back, do we even need the READY state or it be merged it into PENDING?
Currently, the only differences are:
 * update() cannot be called in READY - I think this is a bug (see the
discussion starting at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c23).
 * READY cannot transition to ERROR - I think this is a bug (see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798#c11).
 * The ready event is fired when transitioning to READY
 * As a result of the separation, the ready and message events cannot be fired
as part of the same algorithm. (See the loadSession() discussion below.)


In the state transition diagram, if we make both READY arrows go to PENDING, we
can remove the READY state. We'd probably want to rename PENDING, but that's a
minor issue.

Alternatively, we can leave the two states distinct but add:
 * A MESSAGE arrow that loops back to the READY state
 * An arrow for ERROR
 * Appropriate modifications to the algorithms such that the states are
essentially the same.

The distinct states may be easier to reason about and name (and leave
flexibility for future changes), but it adds duplicate checks as well as logic
in the update() algorithm to describe which state to enter. The distinct states
do make it easy to reason about when to fire a ready event if we want to limit
it to the PENDING->READY transition.


The steps above could also happen when loading a session:
 0a. loadSession()
 0b. Session is found and a ready event is fired, transitioning to the READY
state.
 1-3. Same as above.

However, looking at the loadSession() algorithm, this flow may not be
appropriate and the separation of PENDING and READY is problematic. In the
loadSession() scenario above, the existing loadSession() algorithm would have
implementations fire the keymessage and transition to PENDING then wait for an
update() call before firing the ready event. This behavior is undesirable for
applications. For loadsession(), at least, I think we need to allow firing both
a ready and message event. Otherwise, CDMs must suppress a true response to "If
a message exchange (e.g. a license request) is required" OR applications will
have to wait for a successful license exchange before getting a ready event,
which is undesirable from a user experience perspective.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 10 January 2014 23:26:17 UTC