Blimp: Add BlobChannelSender implementation

blimp/net/blob_channel/blob_channel_sender.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_BLOB_CHANNEL_BLOB_CHANNEL_SENDER_H_
+#define BLIMP_NET_BLOB_CHANNEL_BLOB_CHANNEL_SENDER_H_
+
+#include <set>
+#include <string>
+#include <vector>
+
+#include "base/macros.h"
+#include "base/threading/thread_checker.h"
+#include "blimp/net/blimp_net_export.h"
+#include "blimp/net/blob_channel/types.h"
+
+namespace blimp {
+
+class BlobCache;
+
+// Sends blobs to a remote receiver.
+// The transport-specific details are provided by the caller using the Delegate
+// subclass.
+class BLIMP_NET_EXPORT BlobChannelSender {
+ public:
+  // Delegate interface for transport-specific implementations of blob transfer
+  // commands.
+  class Delegate {
+   public:
+    // Send blob |id| with payload |data| to the receiver.
+    virtual void Deliver(const BlobId& id, BlobData data) = 0;

[Wez, 2016/04/19 00:01:57]

nit: Suggest DeliverBob, in case the implementer delivers other things ;)

[Kevin M, 2016/04/19 23:39:23]

Done.

+  };
+
+  // Caller is responsible for ensuring that |cache| and |delegate| outlive
+  // |this|.
+  BlobChannelSender(BlobCache* cache, Delegate* delegate);

[Wez, 2016/04/19 00:01:57]

Can/should the Sender own the cache object?

[Kevin M, 2016/04/19 23:39:23]

Hmmm. I don't have a reason why not. Made |cache| and |delegate| unique_ptr.

+  ~BlobChannelSender();
+
+  // Puts a blob in the local BlobChannel. The blob can then be pushed to the
+  // remote receiver via "Deliver()".
+  // Does nothing if there is already a blob |id| in the channel.

[Wez, 2016/04/19 00:01:57]

As previously discussed, what if |data| is different for an existing |id|? 
Would it be cleaner to have the caller able to query whether an Id is already in
the channel and _then_ Put() it iff it's not, so that we avoid the BlobData
construction/copy overhead?

[Kevin M, 2016/04/19 23:39:23]

|id| is content-keyed, so it's safe to assume that there shouldn't be collisions
like this.

[Wez, 2016/05/03 22:11:05]

Could we just pass |data| and calculate the Id internally, then, eliminating any
scope for the caller messing-up? That might work best if BlobDataPtr became
BlobPtr and Blobs then include a cached Id field, set at construction time.

+  void Put(const BlobId& id, BlobData data);
+
+  // Sends the blob |id| to the remote side, if the remote side doesn't already
+  // have the blob.

[Wez, 2016/04/19 00:01:57]

Sorry, still not clear from this interface why Put and Deliver are separate -
why would I ever "put" something in the channel if I _don't_ want it to be
"delivered"?

[Kevin M, 2016/04/19 23:39:23]

As discussed offline - breaking this into different calls gives us the
flexibility to specify when and how the data is delivered.

[Wez, 2016/05/03 22:11:04]

Acknowledged.

+  void Deliver(const BlobId& id);
+
+ private:
+  BlobCache* cache_;
+  Delegate* delegate_;
+
+  // A set of the cache item IDs in the receiver's cache.
+  // Allows the sender to determine if a cache item should be sent to the
+  // receiver.
+  std::set<BlobId> receiver_cache_contents_;

[Wez, 2016/04/19 00:01:57]

This won't work well if the Client-side has a purgeable cache, since we may
no-op a Put(), thinking that the content is already there, only to discover that
it is not because of purge - the Client will presumably report back that it is
missing an entry, but by then we have no way of passing it the content, unless
the caller provides it again?

Should we allow the caller to express whether an item is relevant, and therefore
should be retained locally, until the peer confirms that it has made use if it?
e.g. have the call return a dummy object, or token, which it can retain to
express continued interest in that Blob? Then if/when the Client confirms that
it has processed the affected update you might relinquish interest in it, making
it a high-priority candidate for discard.

[Kevin M, 2016/04/19 23:39:23]

We don't have the ability to control data retention in the client - the simple
disk cache's retention policy is kind of a black box for us. That leaves us with
snapshots of the client's cache contents which might be out-of-date for the
intervals between eviction and notification. Allowing the client to make
explicit requests in those instances satisfies those async edge cases.

[Wez, 2016/05/03 22:11:05]

Acknowledged.

+
+  DISALLOW_COPY_AND_ASSIGN(BlobChannelSender);
+};
+
+}  // namespace blimp
+
+#endif  // BLIMP_NET_BLOB_CHANNEL_BLOB_CHANNEL_SENDER_H_