Re: Allow page to designate a default presentation URL

Hi,

Thanks for taking this up Anssi!  I'm back from a trip and have thoughts
below.

I like Anssi's <link rel="presentation" href="..."/> idea; specifically:

-The page can change the href of this element after the fact, to allow it
to interactively change the default presentation.
-The presence of <link rel="href"> *and* screen availability would signal
the UA to offer presentation as an option to the user outside the page.
- When the user initiates presentation from the UA, it would take the
current href of the <link> element as the presentation URL.

On Tue, Nov 11, 2014 at 8:02 AM, Anton Vayvod <avayvod@google.com> wrote:

> Hi Kostiainen et al!
>
> On Tue, Nov 11, 2014 at 3:19 PM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
> >
> > Hi Louay, MarkFo,
> >
> > > On 11 Nov 2014, at 16:50, Bassbouss, Louay <
> louay.bassbouss@fokus.fraunhofer.de> wrote:
> > >
> > > If I understand correctly, we need to extend the spec to let the
> origin page receive the session created by the Browser?
> >
> > MarkFo - how do you see the session object delivered in a scenario where
> the user initiates the presentation from the UA's user interface?
>
> 1) Through an uninitialized "presentation.default" PresentationSession
> object? The UA can't initiate the default presentation until onstatechange
> has a listener attached? Should we then set the default presentation URL
> via the object rather than the meta/link tag? Then the page can actually
> change the default presentation URL on the go.
>

This seems like a chicken and egg; the page can't add a handler to
onstatechange until it has the session.

I would propose adding an ondefaultpresentation
handler/DefaultPresentationEvent that would convey new PresentationSessions
that were initiated by the UA.


> 2) Through a more generic event that would work for both page and UA
> started sessions that the page could join? It could potentially be used
> instead of the Promises for start/joinSession.
>
> presentation.onsessioninitiated = function(e) {
>   setSession(e.presentationSession);
> };
>

Because each invocation of start/join results in zero or one
PresentationSession, Promises are a natural fit.

The default presentation may be initiated multiple times over the lifetime
of the page (each generating its own PresentationSession) so an event
handler is more natural (or at least until stream-based Promises are part
of the Web).

Reference: http://www.w3.org/2001/tag/doc/promises-guide

>
> > > Another question, how the origin page can pass a session id to join an
> existing session?
> >
> > Does it make sense to scope this "implicit invocation" (throught the UA
> UI) use case more tightly to new sessions only? For joining to existing
> sessions, the programmatic API could be used.
> >
> > Are both the "implicit invocation" and the programmatic API attempting
> to address the same use cases i.e. are we striving for feature parity
> between the two? If so, it may cause problems since the programmatic API
> tends to be more expressive by design.
>
> If there's an existing presentation session going on, the page should be
> able to find the presentation id itself (i.e. via the local storage) and
> join the session without any user action. There's no need for the default
> presentation URL in this case.
>

I agree; I don't see a need to support programmatic join behavior in this
scenario.  We do need to ensure that a page can try (and fail) to
programmatically join a presentation before setting a default presentation
URL, so the page can prioritize auto-resumption vs. initiation of a new
presentation session.


>
> > what is the relationship between [1] and [3]?
>
> The default presentation URL could be used by the UA to create a filter
> for device availability.
>

Agreed; for consistency the I feel that the UA should offer the same screen
availability to the page via onavailablechange and through the browser UI.
Thus it makes sense to use the default presentation URL to filter the
screens available to the page.

If there is a use case where we would want different sets of screens
available via the browser and the page then I would be interested in
hearing it.  We might be able to add some metadata to the <link> tag to
handle this case if it's warranted.

Cheers,
m.


>
> >
> > Thanks,
> >
> > -Anssi
>