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

remoting/proto/event.proto

 // 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.
 
 // Protocol for event messages.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
@@ skipping 30 matching lines @@
   // These values encode the number of wheel 'ticks' (sometimes called
   // 'clicks' although 'ticks' is the most common cross-platform term).
   // Additional fields may be added later to support high-resolution devices.
   optional int32 wheel_offset_x = 3;
   optional int32 wheel_offset_y = 4;
 
   // Mouse button event.
   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;
+}