Mojo cpp bindings: add support for validating incoming messages.

mojo/public/cpp/bindings/lib/router.cc

Index: mojo/public/cpp/bindings/lib/router.cc
diff --git a/mojo/public/cpp/bindings/lib/router.cc b/mojo/public/cpp/bindings/lib/router.cc
index ec68bba9459bf2b73754a9ee1ec648022ebb1227..74dced1dcf13d69e71a17b3dbe0bfa77e5a2cc2d 100644
--- a/mojo/public/cpp/bindings/lib/router.cc
+++ b/mojo/public/cpp/bindings/lib/router.cc
@@ -62,13 +62,17 @@ bool Router::HandleIncomingMessageThunk::AcceptWithResponder(
 
 // ----------------------------------------------------------------------------
 
-Router::Router(ScopedMessagePipeHandle message_pipe, MojoAsyncWaiter* waiter)
-    : connector_(message_pipe.Pass(), waiter),
+Router::Router(ScopedMessagePipeHandle message_pipe,
+               FilterChain validators,
+               MojoAsyncWaiter* waiter)
+    : thunk_(this),
+      validators_(validators.Pass()),

[darin (slow to review), 2014/05/14 06:51:51]

s/validators/filters/

[yzshen1, 2014/05/14 08:14:03]

Done.

+      connector_(message_pipe.Pass(), waiter),
       weak_self_(this),
       incoming_receiver_(NULL),
-      thunk_(this),
       next_request_id_(0) {
-  connector_.set_incoming_receiver(&thunk_);
+  validators_.set_sink(&thunk_);
+  connector_.set_incoming_receiver(validators_.GetHead());

[darin (slow to review), 2014/05/14 06:51:51]

maybe set_sink and GetHead could be combined since after you set the sink it
doesn't make sense to continue appending? maybe GetHead could just take a
MessageReceiver pointer, or we could call this method something like "Finish"
instead?

FilterChain feels very much like a builder interface. You could maybe do
something like this:

  FilterChain::Builder builder;
  builder.Append(..)
         .Append(..)
         .Append(..);
  FilterChain chain = builder.Finish(sink);
  // |chain| is now immutable

Perhaps |chain.head()| could return a MessageReceiver*?

This implies passing a FilterChain::Builder to Router. That seems a bit
unfortunate and slightly awkward, but not terrible :-/

Maybe a simpler solution would be to just make Router's FilterChain member be
const but ctor parameter be non-const! Then that would deny access to Append and
Finish when used after the ctor. You could just finish the setup of FilterChain
in the Router constructor and then when done .Pass() it into the const member
variable.

[yzshen1, 2014/05/14 08:14:03]

FilterChain was implemented to work correctly even if we continue appending
after setting the sink or calling GetHead(). (One caveat is that the head will
change when going from 0 to 1 filter, so GetHead() should be called to get the
new head.)
Comparing with passing a FilterChain::Builder, maybe we could do it this way:
- FilterChain doesn't have sink-related member/methods;
- Define a new FilteredReceiver class:
class FilteredReceiver : public MessageReceiver {
  FilteredReceiver(FilterChain filters, MessageReceiver* sink); // takes
ownership of both
};

This way, FilterChain acts like a builder and we avoid the confusion of passing
a builder to Router.
One drawback is that we will have one extra layer to call:
FilteredReceiver::Accept(). Maybe that performance cost is negligible?
What do you think?

Thanks!

 }
 
 Router::~Router() {