Re: Two more issues for the tracker

Hi Anssi,

Thanks for the comments.  Responses inline.

On Mon, Sep 15, 2014 at 7:34 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi MarkFo, Yuri, Anton, All,
>
> From [1]:
>
> On 10 Sep 2014, at 21:01, mark a. foltz <mfoltz@google.com> wrote:
>
> > My colleagues Yuri and Anton have begun prototyping parts of the
> Presentation API in Chromium and raised the following issues which I don't
> believe are covered in the current specification.   Listed here and filed
> in GH.
> >
> > (1) Are multiple simultaneous calls permitted to startSession()?  My
> intuition is "no", but I would like to ask the group if there are any use
> cases where this is necessary.  If the answer is "yes" it adds some
> constraints and complexity to the user interface for screen selection in
> the browser.
> > https://github.com/webscreens/presentation-api/issues/21
>
> You mean that until the promise returned by startSession() has resolved,
> any subsequent calls to startSession() would do nothing, that is the other
> promise returned by subsequent calls would not resolved either?
>

Yes.   Here is an example.  The first call to |startSession()| will ask the
user to select a screen before resolving p1.  In the meantime the page
makes another presentation request.

var p1 = startSession(myUrl);
var p2 = startSession(myUrl2);

Here is what I had in mind:

(1) First call to startSession(myUrl) shows the dialog and returns a
Promise.
(2) At this point any further calls to startSession() from within the same
top level document (i.e., tab) return a Promise that never resolves.
(3a) If the user accepts the presentation request, the Promise in #1
resolves with the PresentationSession.
(3b) If the user rejects the presentation request, the Promise in #1 never
resolves.
(4) After (3a) or (3b) happens, calls to startSession() will return a
Promise that resolves in the normal way (same as #1).

If we allow concurrent calls to startSession() from the same document, then
we would have to queue them up and it would be a confusing user experience
to show multiple dialogs (how would they know which content is requesting
what).

Practically speaking, this is unlikely to happen (at least in Chromium):
the screen selection dialog is modal, blocking user input to the underlying
page, and if possible, we will likely require a user gesture to cause the
invocation of startSession().


>
> Please feel free to provide an example to illustrate what you mean if I
> did not get this right.
>
> All - to provide more context for this, see MarkFo’s recent PR [2]
> summarized at [3]. The HTML version with the PR is at [4].
>
> MarkFo - there are still some traces of requestSession() in the sections 5
> and 5.4 in your PR [2].
>

Thanks for the heads up.  I will be sending a revised PR incorporating
feedback from you and Jonas [1]

[1] http://lists.w3.org/Archives/Public/public-webscreens/2014Sep/0058.html

m.



>
> Thanks,
>
> -Anssi
>
> [1] https://github.com/webscreens/presentation-api/issues/21
> [2] https://github.com/webscreens/presentation-api/pull/23
> [3]
> http://lists.w3.org/Archives/Public/public-webscreens/2014Sep/0031.html
> [4] http://mfoltzgoogle.github.io/presentation-api/
>
>
>