- From: Rottsches, Dominik <dominik.rottsches@intel.com>
- Date: Wed, 15 Jan 2014 14:53:49 +0000
- To: "public-webscreens@w3.org" <public-webscreens@w3.org>
- CC: JC Verdie <jicheu@yahoo.fr>
Hi JC, On 15 Jan 2014, at 00:48, JC Verdie <jicheu@yahoo.fr<mailto:jicheu@yahoo.fr>> wrote: [�] I wanted to say again that I don�t think this group should work on the two UA case, which is already covered elsewhere in the W3C. Depending on how the group works and where it�s headed, it might be a good thing to communicate with other groups but I�d rather avoid having two places for the same discussion. Moreover, the one UA case is very specific and leads to various new opportunities and should be handled with care. That�s already a lot on one�s plate AFAIC. Thanks for explaining your concerns. I agree that we should keep our work in this CG in scope and not try to solve problems which are already handled in other groups. What Anton and I suggested was one change to decouple primary and secondary screen: moving away from returning a WindowProxy (which enables full DOM access) to instead having a loser coupling, based on a MessagePort. This helps in various ways: It does make a possible implementation based on independent UAs easier (which would in principle be also possible with WindowProxy, just more complicated), but it also makes a single UA implementation easier: A tight coupling between primary page and secondary page - enabling DOM access - is tricky to handle on the implementation side, especially in browsers that implement a cross-process / renderer-process isolation model. We do not actually intend to specify whether an implementation is to be based on or two UAs. As also explained in the charter [1], this is considered an implementation detail. We also do not intend to specify something like a cross-vendor bridge for MessagePort. Wes correctly pointed out that that problem is solved through PeerConnection. Practically speaking, by having a less tight coupling between the primary page and the second one we give more flexibility to the implementor, and help adoption of the API. Dominik [1] https://github.com/webscreens/presentation-api/wiki/Second-Screen-Community-Group-Charter#out-of-scope
Received on Wednesday, 15 January 2014 14:58:03 UTC