Re: Updated PR: Promises -> State Transitions

Thanks for your patience Dominik. :)

I reviewed the PR and it looks pretty good.  I feel the event based
semantics are cleaner and easier to implement as we can propagate events
from the Presentation API backend in the browser to the client/renderer,
instead of keeping track of unresolved Promises.   However, I also like
that the |presentationId| can be generated by the UA instead of requiring
the developer to come up with something pseudorandom.

In the code sample, I feel that the show button should be disabled until
the join attempt returns a disconnected session object.  That would prevent
the user from launching a new presentation while the join operation was
pending.  Or do these lines handle that case?

   var sessionPendingOrConnected = sessionConnected ||

        (session && session.state == "unknown");
   showButton.disabled = !screenAvailable || sessionPendingOrConnected;


It might be helpful to be explicit in the document about the state
transitions for |PresentationSession.state|.  Here is what I had in mind:

                 ____________
               v            |
            UNKNOWN---User cancels
               |
         User consent
              /\
             /  \
            /    \
            v     v
    CONNECTED <-> DISCONNECTED

Basically, the session begins as UNKNOWN, remains UNKNOWN if the user
cancels, and then transitions to CONNECTED or DISCONNECTED based on the
outcome of the connection attempt.

I could also see adding CONNECTING state that would happen between user
consent and CONNECTED/DISCONNECTED; this would help the page transition
from presenting content inline to presenting content remotely while the
connection is established, for example, pausing local playback.

Inline, I have a few comments about the open issues in the PR.

Do we need to insert into the description an additional permission prompt
to grant the page access to the "one ore more screens are available"
Information?

MF: I think this depends on what the page can learn from knowing that a
screen is available, in combination with other information.  It's the
latter part that gives me pause.

Do we reload the presentation page after startSession() if the page was
previously already shown on this screen?

MF: With joinSession available I think startSession should always generate
a new session (i.e. reload the presentation page).

If there are already connected screens when the page subscribes to the
onavailablechange event, we can handle this in two ways: We can synthesize
one initial event to notify the page about available screens as soon as the
first event handler is installed (as described). Or we can add another
message likenavigator.presentation.getAvailable(function(available) { } ); to
notify the page about available screens using this one-time asynchronous
getter. Which way should we go?

MF: I think this was discussed in another thread; I'll defer to discussion
there.

Do we need an additional state like resumed in order to identify resumed
session? It seems that this could be handled on the page level. The opener
page could ask the presentation page whether it is "new" or "resumed".

MF: Agreed, if the presentation page knows that a controlling page has been
connected.  It could be part of a handshake protocol between a controlling
page and the presentation page.

If more than one presentation session exists with the same url and
presentationId (on different screens) then what is the behavior of
joinSession(url,
presentationId)? This can be resolved by having the UA generate different
ids on different screens.

MF: This could still happen if the opener page provides the presentationId.

If the page calls startSession(url) and joinSession(url, presentationId) with
the same url, and the latter call has not resolved, behavior is not defined.

MF: I think this can be handled by always returning distinct
PresentationSessions for each invocation of start/join (since we won't know
if they correspond to the same presentation page until the screen
selection/connection process has completed).  If the call to joinSession()
returns a presentation session that is disconnected it knows that
startSession() will be a new presentation page.




Best,
m.


On Sun, Sep 28, 2014 at 3:13 PM, mark a. foltz <mfoltz@google.com> wrote:

> Hello Dominik and Jonas,
>
> Thank you for preparing the comparative merge requests.  I am on vacation
> at the moment but will try to review these as soon as I have a bit of time
> to digest them :)  By the end of this  week at the latest.
>
> Mark
>
>
> On Mon, Sep 22, 2014 at 8:20 AM, Rottsches, Dominik <
> dominik.rottsches@intel.com> wrote:
>
>> Hi MarkFo, Jonas,
>>
>> based on your pull request, Jonas, I edited the PR to move from the
>> Returning-Promises approach to returning
>> PresentationSession-In-Unknown-State approach. It'd be great if you
>> could take a look and review this proposal.
>>
>> The PR is here:
>> https://github.com/webscreens/presentation-api/pull/25
>>
>> The new example code can be found here:
>> http://drott.github.io/presentation-api/#example
>>
>> And explanations following below:
>> http://drott.github.io/presentation-api/#starting-new-presentations
>>
>> Other changes: I simplified the example and explanations to use an
>> auto-generated session.id.
>>
>> Let's try to conclude on this issue and soon merge a version we can all
>> agree to.
>>
>> Dominik
>>
>>
>