Serialize a subset of WebInputEvents to protobufs.

blimp/net/input_message_generator.h

+// 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.
+
+#ifndef BLIMP_NET_INPUT_MESSAGE_GENERATOR_H_
+#define BLIMP_NET_INPUT_MESSAGE_GENERATOR_H_
+
+#include "base/memory/scoped_ptr.h"
+#include "blimp/net/blimp_net_export.h"
+
+namespace blink {
+class WebInputEvent;
+}
+
+namespace blimp {
+
+class InputMessage;
+
+// Handles creating serialized InputMessage protos from a stream of
+// WebInputEvents.  This class may be stateful to optimize the size of the
+// serialized transmission data.  See InputMessageProcessor for the deserialize
+// code.
+class BLIMP_NET_EXPORT InputMessageGenerator {
+ public:
+  InputMessageGenerator();
+  virtual ~InputMessageGenerator();

[Wez, 2015/11/17 01:37:40]

nit: Does this need to be virtual? Will we ever sub-class?

[David Trainor- moved to gerrit, 2015/11/17 05:33:14]

Good point it doesn't.  I should also add DISALLOW_COPY_AND_ASSIGN.

+
+  // Create an InputMessage that represents the WebInputEvent |event|.  This
+  // might make use of state from previous messages.
+  void GenerateMessage(const blink::WebInputEvent& event,
+                       InputMessage* message);

[Wez, 2015/11/17 01:37:40]

Kevin's latest MessageProcessor API takes BlimpMessages via scoped_ptr, so you
could have this API return the message that way, as well.

nit: Given that part of making this an object rather than static methods is to
decouple the two forms of input stream, it would be more flexible to have this
explicitly supplied w/ the MessageProcessor to which the InputMessage should be
sent - up to you, though; we can always try it this way and change that later if
need be.

[David Trainor- moved to gerrit, 2015/11/17 05:33:14]

Ah yeah I saw that.  I wasn't quite sure I could do it because if I have to join
Input and Compositor message types they'd need to share a processor right?  I
sent an email about it.  We can discuss it there then I can make the relevant
changes here :).

[Wez, 2015/11/18 02:18:32]

It's feasible to have two distinct MessageProcessors, for different types (or
even for the same type), writing to a single underlying channel.

[David Trainor- moved to gerrit, 2015/11/18 08:26:30]

Oh sorry I misread your comment!  Will add.

[David Trainor- moved to gerrit, 2015/11/19 00:49:43]

Looked into adding it and I think it would be cleaner without it (when I merge
it with the other CL that builds the whole BlimpMessage I'll see if it could be
added).  The issue is it would probably be cleaner if this class didn't care
about things like tab_id, render_widget_id, session_id, etc. that are required
to actually build a BlimpMessage.  The higher level object could manage that.  I
think this will fit really nicely into the serialization flow though.

[Wez, 2015/11/23 22:41:41]

There's no requirement for this object to set those fields; you'd simply have it
take the target MessageProcessor and document that it, or some other
MessageProcessor in the pipeline, it responsible for setting those fields
appropriately - so you're just using the interface to decouple the
WebInputEvent:BlimpMessages from a 1:1 relationship.

+};
+
+}  // namespace blimp
+
+#endif  // BLIMP_NET_INPUT_MESSAGE_GENERATOR_H_