Create a PPAPI host for new resource message routing.

ppapi/host/resource_host.h

+// 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.
+
+#ifndef PPAPI_HOST_RESOURCE_HOST_H_
+#define PPAPI_HOST_RESOURCE_HOST_H_
+
+#include "base/basictypes.h"
+#include "ppapi/c/pp_resource.h"
+#include "ppapi/host/ppapi_host_export.h"
+#include "ppapi/shared_impl/host_resource.h"
+
+namespace IPC {
+class Message;
+}
+
+namespace ppapi {
+namespace host {
+
+struct HostMessageContext;
+class PpapiHost;
+
+// Some (but not all) resources have a corresponding object in the host side
+// that is kept alive as long as the resource in the plugin is alive. This is
+// the base class for such objects.
+class PPAPI_HOST_EXPORT ResourceHost {
+ public:
+  ResourceHost(PpapiHost* host, PP_Instance instance, PP_Resource resource);
+  virtual ~ResourceHost();
+
+  PpapiHost* host() { return host_; }
+  PP_Instance pp_instance() const { return pp_instance_; }
+  PP_Resource pp_resource() const { return pp_resource_; }
+
+  // Handles messages associated with a given resource object. If the flags
+  // indicate that a response is required, the return value of this function
+  // will be sent as a resource message "response" along with the message
+  // specified in |*optional_reply|.
+  //
+  // You can do a response asynchronously by returning PP_OK_COMPLETIONPENDING.
+  // This will cause the reply to be skipped, and the class implementing this
+  // function will take responsibility for issuing the callback later.
+  //
+  // If you don't have a particular reply message, you can just ignore
+  // |optional_reply|. However, if you have a reply more than just the int32_t
+  // result code, just set |*optional_reply| to be the message of your

[dmichael (off chromium), 2012/06/22 16:56:49]

s/optional_reply/context.reply_msg?

Or...  maybe split it out in to the params and the reply message? It seems like
maybe you had it that way at one point, and that might be less confusing. Right
now it's an in-out parameter, where the context struct has one pure (the params
object) in and one more-or-less pure out (the message)

[brettw, 2012/06/24 04:42:08]

Why there's a weird in/out struct is a long story:

Right now none of the message macros work with resource messages. This means you
have to manually unpack and dispatch each messagee (see
OnResourceMessageReceived in:
http://codereview.chromium.org/10544089/diff/12001/content/renderer/pepper/pe...
)
rather than use IPC_MESSAGE_HANDLER which is a huge pain.

I'm planning (but haven't yet) on adding a new macro for dispatching IPC
messages that passes an additional parameter from the caller to the message
handler. I don't want to add more than one parameter because this will explode
some tuple stuff (I need to add some templates to concatenate tuples). So this
is why I put all the extra info each message handler will need into one param.

+  // choosing.
+  //
+  // The default implementation just returns PP_ERROR_NOTSUPPORTED.
+  virtual int32_t OnResourceMessageReceived(const IPC::Message& msg,
+                                            HostMessageContext* context);
+
+ private:
+  // The host that owns this object.
+  PpapiHost* host_;
+
+  PP_Instance pp_instance_;
+  PP_Resource pp_resource_;
+
+  DISALLOW_COPY_AND_ASSIGN(ResourceHost);
+};
+
+}  // namespace host
+}  // namespace ppapi
+
+#endif  // PPAPI_HOST_RESOURCE_HOST_H_