Re: Allow page to designate a default presentation URL

Hello,

Just wanted to solicit any additional feedback.  I plan on making a pull
request with my most recent proposal and would like to solicit any
additional input.

Anssi et al, how would you like to move forward with these sorts of changes
- would you (or I) propose a call for consensus once a pull request has
been created?

m.


On Mon, Nov 17, 2014 at 2:34 PM, mark a. foltz <mfoltz@google.com> wrote:

> 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
>>
>
>