Mojo cpp bindings: add support for validating incoming messages.

mojo/public/cpp/bindings/lib/message_validator.h

Index: mojo/public/cpp/bindings/lib/message_validator.h
diff --git a/mojo/public/cpp/bindings/lib/message_validator.h b/mojo/public/cpp/bindings/lib/message_validator.h
new file mode 100644
index 0000000000000000000000000000000000000000..0f5ed39a201393f2134aad16708d30ac744d3d3f
--- /dev/null
+++ b/mojo/public/cpp/bindings/lib/message_validator.h
@@ -0,0 +1,38 @@
+// Copyright 2014 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 MOJO_PUBLIC_CPP_BINDINGS_LIB_MESSAGE_VALIDATOR_H_
+#define MOJO_PUBLIC_CPP_BINDINGS_LIB_MESSAGE_VALIDATOR_H_
+
+#include "mojo/public/cpp/bindings/message.h"
+#include "mojo/public/cpp/system/macros.h"
+
+namespace mojo {
+namespace internal {
+
+// This class is the base class for message validators. Subclasses should
+// implement the pure virtual method Accept() inherited from MessageReceiver.
+class MessageValidator : public MessageReceiver {

[darin (slow to review), 2014/05/12 17:28:26]

Hmm... there's nothing about this class that makes it inherently about message
validation. Maybe it would be good to use a name that more accurately describes
this class and in doing so provide a more generic system? Suppose if this were
called ChainedMessageReceiver, FilteringMessageReceiver or maybe just
MessageFilter? Yeah, I kind of like the latter.

MessageFilter could just have a "next" property that is a MessageReceiver. That
MessageReceiver could be a stub or it could be another MessageFilter.

The ValidationChain could be named FilterChain. This would make it possible to
use this system to not just validate incoming messages but also mutate them /
copy them to a logging system / etc. You might be able to build some interesting
things as message filters.

Also, perhaps it would make sense to implement the filter chain as a singly
linked list? Each MessageFilter could own the next MessageReceiver? Then,
FilterChain might just be a type that you use temporarily on the stack to help
you build up the singly linked list.

[yzshen1, 2014/05/12 21:59:58]

I like the name of MessageFilter!
Making FilterChain a builder is a little awkward: we need to append several
filters to the builder, pass the builder into Router, and let Router append the
last one (Router::HandleIncomingMessageThunk) to create the singly linked list.
It seems that more refactoring is required to go with the
builder+singly-linked-list idea.

A relevant issue for discussion:
I have the feeling that it might be good to split the MessageReceiver interface.
The AcceptWithResponder() method is not needed in many cases. For example:
- the responder passed into AcceptWithResponder();
- MessageFilter;
- the receiver passed into ReadAndDispatchMessage();
- the receiver implemented by Connector, as well as the incoming receiver passed
into Connector.

Maybe we could put it in a new interface which also inherits MessageReceiver.
What do you think?

+ public:
+  // Doesn't take ownership of |next|. Therefore |next| has to stay alive while
+  // this object is alive. If |next| is NULL, set_next() has to be called before
+  // this object can be used to validate messages.
+  explicit MessageValidator(MessageReceiver* next = NULL);
+  virtual ~MessageValidator();
+
+  void set_next(MessageReceiver* next) { next_ = next; }
+
+ protected:
+  MessageReceiver* next_;
+
+ private:
+  // MessageReceiver method that shouldn't be reached.
+  virtual bool AcceptWithResponder(Message* message,
+                                   MessageReceiver* responder) MOJO_OVERRIDE;
+};
+
+}  // namespace internal
+}  // namespace mojo
+
+#endif  // MOJO_PUBLIC_CPP_BINDINGS_LIB_MESSAGE_VALIDATOR_H_