Add the plumbing that will carry a clipboard item from a chromoting client to a host.

remoting/protocol/clipboard_stub.h

+// Copyright (c) 2012 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.
+
+// Interface for an object that receives clipboard events.
+// This interface handles some event messages defined in event.proto.
+
+#ifndef REMOTING_PROTOCOL_CLIPBOARD_STUB_H_
+#define REMOTING_PROTOCOL_CLIPBOARD_STUB_H_
+
+#include "base/basictypes.h"
+
+namespace remoting {
+namespace protocol {
+
+class ClipboardEvent;
+
+class ClipboardStub {

[Sergey Ulanov, 2012/03/09 00:23:41]

Do we need separate stub for it? Can it be part of the InputStub? As it
currently works each stub is responsible for one direction of a channel. If we
add ClipboardStub it means that client to host messages sent over the event
channel are split between two interfaces (InputStub and ClipboardStub)

[simonmorris, 2012/03/09 00:34:14]

We'll need to send clipboards from host to client as well (but not in this CL).
So the host will have a ClipboardStub, as well as the client, but it shouldn't
have an InputStub.

[Wez, 2012/03/09 00:44:07]

Yes.  Plus, we don't really want the clipboard data passing via the event
channel anyway, since large transfers will then delay input events.

+ public:
+  ClipboardStub() {}
+  virtual ~ClipboardStub() {}
+
+  virtual void InjectClipboardEvent(const ClipboardEvent& event) = 0;

[Sergey Ulanov, 2012/03/09 00:23:41]

It's not clear whether this goes from the client to the host or from host to
client?

[simonmorris, 2012/03/09 00:34:14]

It can go in either direction (but not in this CL).

+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(ClipboardStub);
+};
+
+}  // namespace protocol
+}  // namespace remoting
+
+#endif  // REMOTING_PROTOCOL_CLIPBOARD_STUB_H_