Added network components for blimp text input feature

blimp/common/proto/blimp_message.proto

 // Copyright 2015 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.
 //
 // Contains the BlimpMessage proto which frames all messages sent over Blimp
 // subchannels. BlimpMessage protos are serialized and transmitted over the
 // wire to the Blimplet server.
 //
 // Each BlimpMessage has a few identifying fields which provide the browser
 // session and tab ID as context. The message details are stored in a
 // feature-specific field (see field IDs 1000 and onward).
 // The |type| field tells the receiving end how the BlimpMessage should
 // be unpacked and which component it should be routed to.
 //
 // CONVENTIONS:
 // * A BlimpMessage can contain only one feature message.
 // * Feature message protos are placed in their own files.
 // * Features are applied to unidirectional channels. Client->server and
 //   server->client channels for a component should be broken out as distinct
 //   features, even if they are conceptually similar.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
 import "compositor.proto";
+import "ime.proto";
 import "input.proto";
 import "navigation.proto";
 import "render_widget.proto";
 import "protocol_control.proto";
 import "tab_control.proto";
 
 package blimp;
 
 message BlimpMessage {
   enum Type {
     UNKNOWN = 0;
     TAB_CONTROL = 1;
     NAVIGATION = 2;
     RENDER_WIDGET = 3;
     INPUT = 4;
     COMPOSITOR = 5;
     PROTOCOL_CONTROL = 6;
+    IME = 7;

[Wez, 2016/03/18 20:51:28]

What is the rationale for adding a top-level ImeMessage rather than folding
these messages under INPUT?

If we keep them separate then can we call it TEXT_INPUT/TextInputMessage?
Without any surrounding context, IME's meaning is not immediately obvious!

[shaktisahu, 2016/03/22 19:44:20]

IME message is both way (client<-->server) whereas INPUT messages are one way. I
can change the name. There are few names I have used so far :
BlimpMessage::IME/ImeMessage, ImeFeature, WebInputBox. Please suggest what seems
more appropriate.

[Wez, 2016/03/22 21:43:38]

Let's stick w/ this for now & revisit naming if it proves troublesome.

   }
 
   // Sequence number of this message, used for message acknowledgement.
   // The sender may omit this value if it is exactly one higher than the
   // message that was previously sent.
   optional int64 message_id = 1;
 
   // Identifies the feature type of this message.
   // The feature-specific contents are contained in optional fields of the same
   // name (example: use |compositor| field for type=COMPOSITOR.)
@@ skipping 13 matching lines @@
   // Feature-specific messages follow.
   // Only one of these fields may be set per BlimpMessage.
   // TODO(kmarshall): use a 'oneof' union when it's supported in Chromium.  See
   // crbug.com/570371.
   optional TabControlMessage tab_control = 1000;
   optional NavigationMessage navigation = 1001;
   optional RenderWidgetMessage render_widget = 1002;
   optional InputMessage input = 1003;
   optional CompositorMessage compositor = 1004;
   optional ProtocolControlMessage protocol_control = 1005;
+  optional ImeMessage ime = 1006;
 }