I agree that having unicast communication to multiple controlling pages is
preferable, and the subsequent proposals on how to do this are reasonable.
For many playback apps, it turns out that you normally want all controlling
pages to be in sync anyways (i.e. most changes in state of the presentation
document are of global interest).
I actually thought about the poker case, before I trimmed it to create a
shorter reply, but if we did want broadcast-only semantics, you can still
implement poker by passing a random key from the controlling page when it
connects.
As a final note, one note to pass along as we discuss channel-related
messaging is that managing connection state can actually be surprisingly
complex. Specifically, especially for long-running sessions, devices may
go through sleep/suspend/wake cycles that can result in transport-level
connection and disconnection. Sometimes a device goes away because it
walked out of the house, other times it goes away because platforms like
iOS kill background connections when you switch apps. The less we think it
necessary to expose specific state about each connected controlling page,
the easier things may be.
Mark.
On Thu, Nov 27, 2014 at 5:19 AM, Francois Daoust <fd@w3.org> wrote:
> 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?
>
>
>> 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.
>
> Francois.
>