Implement BroadcastChannel

components/webmessaging/broadcast_channel.mojom

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module webmessaging.mojom;
+
+interface BroadcastChannelClient {
+  // Messages are passed as SerializedScriptValue.
+  OnMessage(string message);
+};
+
+interface BroadcastChannelService {
+  // Connect to the channel identified by the |origin| and |name|. Messages can
+  // be sent to the channel using |sender|, and messages to the channel will be
+  // received by |receiver|.
+  // All connections to channels made from the same event loop should be made
+  // through the same BroadcastChannelService to ensure correct ordering of
+  // messages.
+  // TODO(mek): Use correct type to represent origin.
+  ConnectToChannel(string origin, string name, associated BroadcastChannelClient receiver, associated BroadcastChannelClient& sender);

[Ken Rockot(use gerrit already), 2016/05/21 00:01:18]

It seems like we could simplify this by avoiding associated interfaces:

  interface BroadcastClient {
    OnMessage(string message)
  };

  interface BroadcastService {
    Subscribe(string origin, string channel_name, BroadcastClient client);
    Broadcast(string origin, string channel_name, string message);
  };

Assuming any given event loop only needs one BroadcastService connection and one
BroadcastClient binding, this should accomplish the same thing?

[Marijn Kruisselbrink, 2016/05/21 00:34:21]

It would be possible to have a mojo API that is more like that, yes. It would
mean I would have to write extra code on the blink side to do all the
multiplexing to get messages to from the correct BroadcastChannel instances. And
with that exact API the client passed to Subscribe would still need to be an
associated interface to get the ordering the spec currently specifies (although
maybe it would be okay to loosen the spec to not use the same "task source" for
different channels, thus allowing the reordering that can happen by having
multiple BroadcastClient pipes).

One big benefit to doing my own multiplexing in blink would be that local
messages can be delivered without an IPC round-trip in between. But I'd
essentially be duplicating all the broadcast channel service code from the
browser process into the renderer process (keeping track of all the active
channel connections, routing the correct messages to the correct channel
instances, etc). I did consider that, but this approach ultimately seemed
simpler, and I don't think the overhead of IPC for same-thread messages is
really going to be a major issue that's going to effect how this API can be
used.

[Marijn Kruisselbrink, 2016/05/21 00:36:15]

And maybe I should just implement it, to see just how ugly/non-ugly it might
get....

[Marijn Kruisselbrink, 2016/05/31 23:40:53]

Okay, I ended up implementing something with a mojom interface much closer to
what you suggested. It certainly resulted in quite a bit more code/logic in the
renderer, but I think the benefits might actually be worth it. And (in the
fourth or so iteration I ended up with) it's not as ugly as I feared it might
get.

+};