Blimp: define HeliumTransport/HeliumStream interfaces.

blimp/net/helium/helium_transport.h

+// 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.
+
+#ifndef BLIMP_NET_HELIUM_HELIUM_TRANSPORT_H_
+#define BLIMP_NET_HELIUM_HELIUM_TRANSPORT_H_
+
+#include <memory>
+
+#include "base/callback.h"
+#include "blimp/net/helium/helium_result.h"
+
+namespace blimp {
+
+// Abstract interface for a HeliumStream factory. Subclasses can use this
+// interface to encapsulate transport-specific stream connection semantics.
+class HeliumTransport {
+ public:
+  // Callback invoked with the stream and result code of a Connect or Accept
+  // attempt.
+  // The HeliumStream is assumed to be authenticated and ready to use.
+  // If the connection attempt failed, the value of |stream| will be null and
+  // |result| will be set to the relevant error code.
+  using StreamCreatedCallback =
+      base::Callback<void(std::unique_ptr<HeliumStream> stream,
+                          HeliumResult result)>;
+
+  class Delegate {
+   public:
+    // Called when the transport transitions between an offline/unsuable state
+    // and an online/usable state.
+    virtual void OnAvailabilityChanged(bool available) = 0;
+  };
+
+  virtual void SetDelegate(std::unique_ptr<Delegate> delegate);
+
+  // Asynchronously attempts to connect a new HeliumStream.
+  // Multiple overlapping connection attempts are permitted.
+  virtual void Connect(const StreamCreatedCallback& cb) = 0;
+
+  // Accepts an incoming connection from the peer.
+  // Multiple overlapping Accept requests are permitted.

[Garrett Casto, 2016/10/05 20:34:05]

Is there any reason why we would ever want to have overlapping Accept() call
outstanding, or is this just trying to give possible flexibility to Sync? 

I agree that it's a tough call between a Delegate (which is consistent with how
we want this call to be used) and Callbacks (which is how the rest of the API is
structured). I'm fine with this for now, and as we start writing code we can see
what issues we run into. 

[Kevin M, 2016/10/05 23:57:58]

Hmmm. I was thinking of erring on the side of flexibility, but I can't think of
a solid use case for having multiple Accepts. Relaxing an interface down the
line is easier than constraining it, so how about I just allow one at a time for
now?

+  virtual void Accept(const StreamCreatedCallback& cb) = 0;

[perumaal, 2016/10/05 20:40:44]

There is no Accept in grpc land. Could we just have the Connect be
SetOnConnectionAccepted(...) callback and merge both?

[Garrett Casto, 2016/10/05 20:53:07]

Take a look at go/helium-transport. Short answer is that we want to be able to
distinguish between initiating a connection and getting a connection that the
other side has initiated. gRPC doesn't do this directly, but we will do it
internally by having gRPC streams we create to service
HeliumTransport::Connect() on the server.

[perumaal, 2016/10/05 22:22:14]

Discussed offline, this is ok for now. thanks!

[Kevin M, 2016/10/05 23:57:58]

What Garrett said.

+
+  // Returns true if the underlying transport has the necessary resources
+  // and connectivity for Connect and Accept operations.
+  virtual bool IsAvailable() = 0;
+};
+
+}  // namespace blimp
+
+#endif  // BLIMP_NET_HELIUM_HELIUM_TRANSPORT_H_