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

Thanks Francois,

CIL

Louay

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: Donnerstag, 27. November 2014 14:20
> To: Mark Scott; Bassbouss, Louay
> Cc: Kostiainen, Anssi; Rottsches, Dominik; Anton Vayvod; public-
> secondscreen@w3.org; public-webscreens@w3.org; mark a. foltz
> Subject: Multiple controlling pages (Was: Re: Allow page to designate itself as
> presentation session)
> 
> On 2014-11-26 04:05, Mark Scott wrote:
> [...]
> > The main gap necessary to allow multiple simultaneous senders is on
> > the messaging side; the sender side doesn't change much, but the
> > presentation session needs to differentiate between senders (can be
> > done at the app level), and needs to be able to send messages back to
> > all senders (ideally, individually, though broadcast could work with
> > app-level filtering).
> 
> Being able to send a private message to a particular sender sounds
> important. Sticking to the Poker example, the Poker table screen would want
> to distribute cards to each sender individually. Cheating would be easy (e.g.
> through custom scripts à la Greasemonkey) if players received the whole
> distribution.
> 
> A broadcast message can easily be emulated with a simple "for" loop and I
> don't think there are many network optimizations that a browser could do to
> implement it differently. Or is there?
[Louay] 
I think for loop is fine to do broadcast.  
> 
> >
> > We'd have to decide if we want this to be in scope, but as the gaming
> > example shows, it is actually useful to support this.
> 
> I note that the possibility to have multiple controlling pages is in
> scope of the working group per charter [1]:
> "pages hosted by other user agents may be authorized to control the
> remotely rendered content *at the same time*."
> 
> Actually, that was one of the requests for clarification received during
> the internal charter review.
> 
> Whatever the solution, it is going to impact how these sessions are
> exposed to receivers since "navigator.presentation.session" is a
> singleton right now. It might be good to handle the possibility for
> receivers to have multiple senders as soon as possible.
[Louay] 
I think we need to clearly describe what a "session" is. Currently session is like a channel. In multiple senders case, we need multiple channels but not necessary multiple sessions. What do you think about this proposal?
session.onconnect = function(evt){
   var c  = e.channel;
   c.postMessage("Hello Sender, you are now connected");
   c.onmessage = function(){...}
   c.onstatechange = function(){...}
}
> 
> Francois.

Received on Thursday, 27 November 2014 14:39:55 UTC