Ansii, Louay, - I agree that mesh (n:n) communication would complicate the spec. Mesh communication could be better served by a separate web service that each presentation participant connects to, distinct from the communication channel offered by the spec. - The scenario for 1:n communication between the presenting and controlling pages should be fleshed out. There could be an explicit API to send a broadcast message, or we provide N different MessagePort-like objects that the presenting page could use to message to all or a subset of controlling pages. Should the 1:n requirement be captured in a separate GH issue? m. On Tue, Nov 18, 2014 at 7:23 AM, Kostiainen, Anssi < anssi.kostiainen@intel.com> wrote: > > On 18 Nov 2014, at 17:02, Bassbouss, Louay < > louay.bassbouss@fokus.fraunhofer.de> wrote: > > > >> Can we assume the controlling pages do not know of each other and the > >> state changes as well as messaging between the controlling pages must be > >> proxies through the presenting page (or some other means defined by > other > >> specs)? > > [Louay] I share the same opinion. I think 1:n communication (1 is > presenting page and n for controller pages) is enough at this stage. n:n > mesh communication will make the spec and implementation more complex. But > If we find use cases where this kind of communication is required, we need > to consider the n:n case. Currently I don’t have a use case in mind. > > The generic n:n comms problem on the Web has not been addressed yet, and > the still experimental BroadcastChannel only proposes a solution to same > origin pages opened by the same user agent. > > Thus it seems reasonable for the group to scope this API to 1:n > communication (All - if you have concerns, please let us know). > > Now, we'd need to tease out the requirements for the 1:n comms after which > we can start to look at concrete spec changes. > > Thanks, > > -Anssi
Received on Friday, 21 November 2014 22:35:12 UTC