Implement BroadcastChannel

components/webmessaging/public/interfaces/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;
+
+import "url/mojo/origin.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.
+  Subscribe(url.mojom.Origin origin, string name, associated BroadcastChannelClient client);

[Ken Rockot(use gerrit already), 2016/06/01 16:07:50]

Sorry, I think I may have lost track of exactly what you want to accomplish by
using an associated interface here. The only possible reason I can come with is
that in the following scenario:

  s.Subscribe(a, b, client1)
  s.Subscribe(a, b, client2)
  s.Subscribe(a, b, client3)
  s.Broadcast(a, b, foo)
  s.Broadcast(a, b, bar)

you want to guarantee that no client dispatches OnMessage(bar) until all three
have dispatched OnMessage(foo). Is that correct?

[Marijn Kruisselbrink, 2016/06/01 21:37:12]

No, that's not the case I'm concerned about. What I'm trying to guarantee is
that in the following scenario:

s1.Subscribe(a, b, client1)
s1.Subscribe(a, c, client2)

s2.Broadcast(a, b, foo)
s2.Broadcast(a, c, bar)

I want to guarantee that client1.OnMessage(foo) is always called before
client2.OnMessage(bar). In the spec all the BroadcastChannel instances in the
same context use the same single task source for the tasks that dispatch their
events, which pretty much means messages have to remain ordered like this.

As a side note, each MessagePort instance has its own task source in the spec,
so it seems like for MessagePort it should at least be spec compliant to not
give any of these guarantees. If such a change is going to web compatible is of
course a different issue, as currently I don't think any implementation actually
makes use of the fact that each port has its own task source.

[Ken Rockot(use gerrit already), 2016/06/01 21:47:08]

Oh, right. I guess it's really the same thing, but my example was overly
specific. That makes sense then.

So what about a case like:

 s1.Subscribe(a, b, client1)
 s1.Subscribe(a, c, client2)

 s2.Broadcast(a, b, foo)

 s3.Broadcast(a, c, bar)

Is it OK that client1.OnMessage(foo) can happen before client2.OnMessage(bar) in
this case?

[Marijn Kruisselbrink, 2016/06/01 22:07:58]

Since (with the implementation that only one BroadcastChannelService connection
is created for any thread) in that case s2 and s3 are guaranteed to be on
different threads (or processes), it is indeed okay that those message can get
delivered in either order. I haven't entirely convinced myself that there aren't
any possible scenarios where ordering/behavior would observably differ from what
the spec defines though. In particular the behavior around closing connections
and what messages "should" be delivered isn't quite possible to fully implement
(or at least very complicated). And I expect any remaining edge cases to be
minor and unlikely enough to in practice not cause any real interop problems.

+  Broadcast(url.mojom.Origin origin, string name, string message);
+};