W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2014

Re: Multiple controlling pages (Was: Re: Allow page to designate itself as presentation session)

From: Francois Daoust <fd@w3.org>
Date: Fri, 28 Nov 2014 16:51:45 +0100
Message-ID: <54789A11.9020604@w3.org>
To: Anton Vayvod <avayvod@google.com>
CC: Mark Scott <markdavidscott@google.com>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "mark a. foltz" <mfoltz@google.com>
Hi Anton,

On 2014-11-27 18:04, Anton Vayvod wrote:
> Hi Francois,
>
> thanks for splitting this issue out of the other thread!
>
> If we consider each client as a separate session, would something like
> 'onconnected' event listener work instead of the
> navigator.presentation.session? E.g.:

Note "onconnect" is probably more consistent with how events are named 
in other specs, e.g. the Web Sockets API.

[...]
> We could also add navigator.presentation.ondisconnected and such (if we
> have more states for sessions) and remove onstatechange from the session?
> The same events could be used in the same manner for the presenting page
> as well although it would change the spec even more.

It would be good to keep the interfaces of the presenting page and the 
requesting page aligned as much as practical. I think I also prefer a 
more object-oriented approach where state changes are triggered on the 
session itself.

To avoid any confusion, what about renaming the "connect" event into 
"session" to say that a new session is established?

The relevant part of your code would become:

navigator.presentation.onsession = function (event) {
   var session = event.session;
   session.onstatechange = onclientstatelistener.bind(null, session);
   session.onmessage = onclientmessage.bind(null, session);
   session.postMessage("Hello Sender");
};

Louay proposes to keep "navigator.presentation.session" as a root object 
(see [1]), which could make sense. This would mean moving things down 
one level and renaming "session" into "channel", as in:

navigator.presentation.session.onchannel = function (event) {
   var channel = event.channel;
   channel.onstatechange = function (ev) { ... };
   channel.onmessage = function (ev) { ... };
   channel.postMessage("Hello Sender");
}

The root session object could be used to retrieve the presentation ID 
and send broadcast messages:

var presentationId = navigator.presentation.session.id;
navigator.presentation.session.postMessage("Hello all senders");

The PresentationSession and PresentationChannel interfaces would be 
roughly the same, except the PresentationSession would have an "id" 
property, and the "onchannel" event handler (only useful on the receiver).

I do not feel strongly one way or the other.

Francois.

[1] 
http://lists.w3.org/Archives/Public/public-secondscreen/2014Nov/0048.html
Received on Friday, 28 November 2014 15:52:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:43 UTC