[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

--- Comment #4 from David Dorwin <ddorwin@google.com> ---
tl;dr: Skip to PROPOSAL below.

(In reply to Mark Watson from comment #3)
> Are you essentially saying that there are two orthogonal aspects to the
> session state ?
> (1) message state: whether it has sent a message and is waiting for a
> response
> (2) ready state: whether the session has the keys it needs for playback
I think I'm saying that the messaging is mostly orthogonal to the active states
(PENDING and READY)[1]. The ready event may be similarly orthogonal. (I think
it's fine to disallow messages, update() calls, and ready events in the ERROR,
CLOSED, or CREATED states.) I'm also questioning the value of the READY state
and - to a lesser extent - the ready event.

> We can be ready for playback without going through a message exchange
> (loadSession).
In this case, the ready event means "loaded/created, no message".

> We can be ready for playback during a message exchange (renewal).
Yes. In this case, the ready event simply served to indicate "initialized, no
message for now" and the renewal request indicates there is a message.


Currently the READY state/event simply indicates there are no more messages to
pass: "The CDM currently has all the information it needs to use keys/licenses
from this session." In practice, this likely means the license request has been
satisfied with all necessary keys, but we don't know for sure. *Neither the
READY state or anything else actually indicates that the session or CDM has the
key needed for playback* - there is no such check in the algorithms and some
formats allow new key IDs to appear in the stream without new Initialization
Data.


We need to decide what we want the 'ready' event to indicate and consider how
app developers might use it. If those two things are not consistent, we might
run into trouble. This seems likely given the confusion about the event's
meaning just within this group. Once we determine the meaning and use cases, we
can determine when we need to fire an event then figure out what the state
machine and algorithms should be.

Below are some potential uses for the current event:
1) Indicate that the session has been initialized (created/loaded) when no
'message' event is needed.
  * This seems like the primary need.
2) There was also a use case for (optionally) firing the event if another
session already exists (PENDING or READY) for the initData. [2][3]
3) There may be a UI-related use case where the application can indicate
whether it is waiting for a key.
  * However, what should the application do during the renewal request?
  * Maybe this use case is best handled by bug 18515.
  * Also, there is no guarantee that the keys are actually present.
4) It could also be used as an ACK for the last update() call, informing the
application there are no more messages (for now).
  * I'm not sure what an application would do with this information (other than
the case above).
  * Aa message _could_ be fired for other reasons, meaning a message does not
definitively acknowledge an update() call.
  * It could be argued that acknowledging an update() call has no effect on
whether the session is "ready".
5) Wait for the 'ready' event before appending data or calling play().
  * There should be no need to do this since playback should start/resume
automatically when the key(s) are available.
  * Also, there is no guarantee that the keys are actually present.

In the discussion of the loadSession() scenario at the end of comment #2, the
'ready' event must fired to avoid problems with applications that might fit
into #1, #3, and/or #5. I'd prefer a simpler, less-ambiguous model.


*** PROPOSAL ***
Since createSession() and loadSession() are asynchronous (and must wait for the
CDM to be initialized), it seems useful to always have an indication that those
functions have completed and are initialized/opened. For discussion purposes, I
propose we fire an 'open' event to transition to the OPEN state. The 'open'
event would be fired unless there is a failure to create/load the session, in
which case the 'error' event is fired. The 'open' event also serves as an
indication that update() may be called.

The OPEN state would replace the current PENDING and READY states. The 'open'
event would be fired before any 'message' event and in place of the 'ready'
event in the transition from CREATED to READY. A unified event/state transition
from CREATED would allow applications to handle a single event if they need to
know that createSession()/loadSession() was successful, the sessionId attribute
is valid, or update() may be called, regardless of whether there are any
messages and without the ambiguity of other 'ready' events/READY state
transitions.

The 'message' event and update() calls have no effect on the OPEN state or
whether the session is "ready" in any way.

The 'close' and 'error' events and their respective states remain unchanged.

The effective differences from the current PENING/READY/'ready' design are:
 * No indication that no messages will be passed for this session (#2).
   - This was never definitive anyway, especially in the loadSession() case.
 * No way to know when a series of messages is complete (#4).
   - Is this important?
 * No way to infer that all keys are now available.
   - This was a misuse of the 'ready' event, so this is an improvement.

Revisiting the use cases above:
 #1 is addressed by the 'open' event. The same event is fired regardless of
whether a 'message' event will be fired.
 #2 could also be addressed by an 'open' event where no 'message' event is
fired. I don't think the app needs to know that no message is necessary for the
session.
 #3 is addressed by bug 18515.
 #4 is not supported.
 #5 was invalid.


[1] Per the discussion starting at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c23, it seems unclear that
we need to track the message state.
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c7
[3] https://dvcs.w3.org/hg/html-media/rev/cba144274140

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

Received on Friday, 17 January 2014 23:52:13 UTC