Update client side navigator.connect API to use ServicePortCollection [2/3]

content/common/service_port_service.mojom

+// Copyright 2015 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 content;
+
+enum ServicePortConnectResult {
+  ACCEPT,
+  REJECT
+};
+
+struct MojoTransferredMessagePort {
+  int32 id;
+  bool send_messages_as_values;
+};
+
+interface ServicePortService {
+  SetClient(ServicePortServiceClient client);
+
+  Connect(string target_url, string origin)
+      => (ServicePortConnectResult result, int32 port_id);
+
+  PostMessage(int32 port_id, string message, array<MojoTransferredMessagePort> ports);

[Tom Sepez, 2015/06/29 18:31:19]

nit: 80 cols.

[Marijn Kruisselbrink, 2015/06/29 19:33:39]

Done.

If that's the required style, somebody should probably add a "mojom" section to
https://www.chromium.org/developers/coding-style
Currently it's pretty unclear what style guide would apply for mojom files. IDL
seems like a logical choice (and doesn't have an 80 col limit currently),
although mojom is of course different from webidl (but even more different than
C++, so it isn't obvious that the c++ style guide would rule here).

+  ClosePort(int32 port_id);
+};
+
+interface ServicePortServiceClient {
+  PostMessage(int32 port_id, string message, array<MojoTransferredMessagePort> ports, array<int32> new_routing_ids);

[Tom Sepez, 2015/06/29 18:31:19]

nit: here too.

+};

[Tom Sepez, 2015/06/29 18:31:19]

do the elements of the two arrays correspond to each other?  If so, it's usually
better to send a single array of structs rather than two parallel arrays, so you
don't have to worry about size mismatches between the two.  Otherwise OK.

[Marijn Kruisselbrink, 2015/06/29 19:33:39]

Yes, the elements correspond to each other. I thought about adding the
new_routing_id to the TransferredMessagePort struct when I introduced that
struct a while ago, but at the time decided against it, since the field only is
meaningful in messages send from the browser to the renderer. Messages that go
the other way never would never need to include it (an alternative would of
course be to have arrays of different structs for messages in either direction,
but that would require more annoying conversion code to pass on a message from
one renderer to the next). 
Maybe that decision was wrong and it would be cleaner to have all attributes in
the same struct and just not use the new_routing_id field for messages to the
browser, but changing that should probably change it all over the place (there
are various IPCs that currently all pass a vector<TransferredMessagePort> and a
vector<int>, and all code on both sides is currently setup to deal with that),
and not just change it here (requiring code on both sides to combine/split the
arrays).

So if you think I should change this to merge new_routing_id into
TransferredMessagePort, I'll gladly do so as a follow-up CL, but I'd prefer to
do that separately.