Upstream version 10.39.225.0
[platform/framework/web/crosswalk.git] / src / ppapi / proxy / dispatch_reply_message.h
1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file.
4
5 // This file provides infrastructure for dispatching messasges from host
6 // resource, inlcuding reply messages or unsolicited replies. Normal IPC Reply
7 // handlers can't take extra parameters. We want to take a
8 // ResourceMessageReplyParams as a parameter.
9
10 #ifndef PPAPI_PROXY_DISPATCH_REPLY_MESSAGE_H_
11 #define PPAPI_PROXY_DISPATCH_REPLY_MESSAGE_H_
12
13 #include "base/callback.h"
14 #include "ipc/ipc_message_macros.h"
15 #include "ppapi/c/pp_errors.h"
16
17 namespace ppapi {
18 namespace proxy {
19
20 class ResourceMessageReplyParams;
21
22 template <class ObjT, class Method>
23 inline void DispatchResourceReply(ObjT* obj, Method method,
24                                   const ResourceMessageReplyParams& params,
25                                   const Tuple0& arg) {
26   (obj->*method)(params);
27 }
28
29 template <class ObjT, class Method, class A>
30 inline void DispatchResourceReply(ObjT* obj, Method method,
31                                   const ResourceMessageReplyParams& params,
32                                   const Tuple1<A>& arg) {
33   (obj->*method)(params, arg.a);
34 }
35
36 template<class ObjT, class Method, class A, class B>
37 inline void DispatchResourceReply(ObjT* obj, Method method,
38                                   const ResourceMessageReplyParams& params,
39                                   const Tuple2<A, B>& arg) {
40   (obj->*method)(params, arg.a, arg.b);
41 }
42
43 template<class ObjT, class Method, class A, class B, class C>
44 inline void DispatchResourceReply(ObjT* obj, Method method,
45                                   const ResourceMessageReplyParams& params,
46                                   const Tuple3<A, B, C>& arg) {
47   (obj->*method)(params, arg.a, arg.b, arg.c);
48 }
49
50 template<class ObjT, class Method, class A, class B, class C, class D>
51 inline void DispatchResourceReply(ObjT* obj, Method method,
52                                   const ResourceMessageReplyParams& params,
53                                   const Tuple4<A, B, C, D>& arg) {
54   (obj->*method)(params, arg.a, arg.b, arg.c, arg.d);
55 }
56
57 template<class ObjT, class Method, class A, class B, class C, class D, class E>
58 inline void DispatchResourceReply(ObjT* obj, Method method,
59                                   const ResourceMessageReplyParams& params,
60                                   const Tuple5<A, B, C, D, E>& arg) {
61   (obj->*method)(params, arg.a, arg.b, arg.c, arg.d, arg.e);
62 }
63
64 // Used to dispatch resource replies. In most cases, you should not call this
65 // function to dispatch a resource reply manually, but instead use
66 // |PluginResource::CallBrowser|/|PluginResource::CallRenderer| with a
67 // |base::Callback| which will be called when a reply message is received
68 // (see plugin_resource.h).
69 //
70 // This function will call your callback with the nested reply message's
71 // parameters on success. On failure, your callback will be called with each
72 // parameter having its default constructed value.
73 //
74 // Resource replies are a bit weird in that the host will automatically
75 // generate a reply in error cases (when the call handler returns error rather
76 // than returning "completion pending"). This makes it more convenient to write
77 // the call message handlers. But this also means that the reply handler has to
78 // handle both the success case (when all of the reply message paramaters are
79 // specified) and the error case (when the nested reply message is empty).
80 // In both cases the resource will want to issue completion callbacks to the
81 // plugin.
82 //
83 // This function handles the error case by calling your reply handler with the
84 // default value for each paramater in the error case. In most situations this
85 // will be the right thing. You should always dispatch completion callbacks
86 // using the result code present in the ResourceMessageReplyParams.
87 template<class MsgClass, class ObjT, class Method>
88 void DispatchResourceReplyOrDefaultParams(
89     ObjT* obj,
90     Method method,
91     const ResourceMessageReplyParams& reply_params,
92     const IPC::Message& msg) {
93   typename MsgClass::Schema::Param msg_params;
94   // We either expect the nested message type to match, or that there is no
95   // nested message. No nested message indicates a default reply sent from
96   // the host: when the resource message handler returns an error, a reply
97   // is implicitly sent with no nested message.
98   DCHECK(msg.type() == MsgClass::ID || msg.type() == 0)
99       << "Resource reply message of unexpected type.";
100   if (msg.type() == MsgClass::ID && MsgClass::Read(&msg, &msg_params)) {
101     // Message type matches and the parameters were successfully read.
102     DispatchResourceReply(obj, method, reply_params, msg_params);
103   } else {
104     // The nested message is empty because the host handler didn't explicitly
105     // send a reply (likely), or you screwed up and didn't use the correct
106     // message type when calling this function (you should have hit the
107     // assertion above, Einstein).
108     //
109     // Dispatch the reply function with the default parameters. We explicitly
110     // use a new Params() structure since if the Read failed due to an invalid
111     // message, the params could have been partially filled in.
112     DispatchResourceReply(obj, method, reply_params,
113         typename MsgClass::Schema::Param());
114   }
115 }
116
117 // Template specialization for |Callback|s that only accept a
118 // |ResourceMessageReplyParams|. In this case |msg| shouldn't contain any
119 // arguments, so just call the |method| with the |reply_params|.
120 template<class MsgClass, class Method>
121 void DispatchResourceReplyOrDefaultParams(
122     base::Callback<void(const ResourceMessageReplyParams&)>* obj,
123     Method method,
124     const ResourceMessageReplyParams& reply_params,
125     const IPC::Message& msg) {
126   DCHECK(msg.type() == MsgClass::ID || msg.type() == 0)
127       << "Resource reply message of unexpected type.";
128   (obj->*method)(reply_params);
129 }
130
131 // When using PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL* below, use this macro to
132 // begin the map instead of IPC_BEGIN_MESSAGE_MAP. The reason is that the macros
133 // in src/ipc are all closely tied together, and there might be errors for
134 // unused variables or other errors if they're used with these macros.
135 #define PPAPI_BEGIN_MESSAGE_MAP(class_name, msg) \
136   { \
137     typedef class_name _IpcMessageHandlerClass ALLOW_UNUSED; \
138     const IPC::Message& ipc_message__ = msg; \
139     switch (ipc_message__.type()) { \
140
141 // Note that this only works for message with 1 or more parameters. For
142 // 0-parameter messages you need to use the _0 version below (since there are
143 // no params in the message).
144 #define PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL(msg_class, member_func) \
145     case msg_class::ID: { \
146       msg_class::Schema::Param p; \
147       if (msg_class::Read(&ipc_message__, &p)) { \
148         ppapi::proxy::DispatchResourceReply( \
149             this, \
150             &_IpcMessageHandlerClass::member_func, \
151             params, p); \
152       } else { \
153         NOTREACHED(); \
154       } \
155       break; \
156     }
157
158 #define PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL_0(msg_class, member_func) \
159   case msg_class::ID: { \
160     member_func(params); \
161     break; \
162   }
163
164 #define PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL_UNHANDLED(code) \
165     default: { \
166         code; \
167     } \
168     break;
169
170 #define PPAPI_END_MESSAGE_MAP() \
171   } \
172 }
173
174 }  // namespace proxy
175 }  // namespace ppapi
176
177 #endif  // PPAPI_PROXY_DISPATCH_REPLY_MESSAGE_H_