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

remoting/proto/event.proto

Index: remoting/proto/event.proto
diff --git a/remoting/proto/event.proto b/remoting/proto/event.proto
index dcc2aaebea7d2dfeeb67fcca54608612886f631c..f51d8ef6b695a09ea59eb329971f55d098619344 100644
--- a/remoting/proto/event.proto
+++ b/remoting/proto/event.proto
@@ -48,3 +48,17 @@ message MouseEvent {
   optional MouseButton button = 5;
   optional bool button_down = 6;
 }
+
+// Defines an event that sends data from one peer's clipboard into the other

[Wez, 2012/03/09 00:34:00]

nit: ... sends clipboard data between peers. ?

[simonmorris, 2012/03/09 00:44:47]

Done.

+// peer's clipboard.
+message ClipboardEvent {

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

We probably want clipboard data on its own channel, so that it interferes less
with input.

+
+  // The type of the data being sent.
+  enum DataType {
+    DATA_TYPE_TEXT_UTF8 = 0;

[Wez, 2012/03/09 00:34:00]

If we're going to go down the route of coding specific types in to the protocol
then wouldn't we be better off defining a ClipboardEvent message for each type,
with type-specific fields, so that this becomes TextClipboardEvent?

Alternatively, we could have a single ClipboardEvent containing just MIME-type
and data fields, and avoid the need to code specific types into the protocol.

[simonmorris, 2012/03/09 00:44:47]

If there are useful type-specific fields for some types, that would make sense.
Do you have examples in mind?
That works too, if MIME-type is always unambiguous enough for us. It just means
there are strings in our code instead of enums, but I don't feel strongly about
it.

[Wez, 2012/03/09 01:12:41]

Text, images and files would likely need different treatment on-the-wire.  Files
may be very large, so we'd want to break them into chunks, provide file
meta-data, etc.  Images may be on the local clipboard in several formats that we
can offer on the remote clipboard, and then just transfer whichever format the
remote end requests.
The client is going to see clipboard data classified by MIME-type anyway, so I
think it'd make sense to take advantage of that existing cross-platform scheme
rather than mapping from it to something Chromoting specific.

Given that hosts might have clipboard data in several formats, advertising
multiple MIME-types and letting the peer choose which to fetch is something we
should consider (although for simple text just pushing the data immediately with
a single type is probably best).

+  }
+  required DataType dataType = 1;
+
+  // The data being sent.
+  required bytes data = 2;
+}