Refactor 4 PPB_Flash functions to the new PPAPI resource model.

ppapi/host/resource_message_handler.cc

Index: ppapi/host/resource_message_handler.cc
diff --git a/ppapi/host/resource_message_handler.cc b/ppapi/host/resource_message_handler.cc
index 9442c1564a21022b29feff22e961bc4aecb7f94d..41a8364713c9d7dded4669264bcabf30bfa7e77c 100644
--- a/ppapi/host/resource_message_handler.cc
+++ b/ppapi/host/resource_message_handler.cc
@@ -22,6 +22,9 @@ void ResourceMessageHandler::RunMessageHandlerAndReply(
     const IPC::Message& msg,
     HostMessageContext* context) {
   ReplyMessageContext reply_context = context->MakeReplyMessageContext();
+  // CAUTION: Handling the message may cause the destruction of this object. If
+  // PP_OK_COMPLETIONPENDING is returned, we should assume that we might have

[yzshen1, 2012/12/14 19:13:14]

Why PP_OK_COMPLETIONPENDING is the only possible outcome that this object may
have been destructed?
(If not, line 53 cannot be called.)

[raymes, 2012/12/17 04:07:57]

Right now I'm making the assumption that if the message handler might cause the
object to be destroyed, it MUST return PP_OK_COMPLETIONPENDING (otherwise line
53 will get called).

[yzshen1, 2012/12/17 05:02:23]

This assumption doesn't look very intuitive. Can it be said here or elsewhere
explicitly?

On 2012/12/17 04:07:57, raymes wrote:

[raymes, 2012/12/17 05:11:00]

I tried to make it clear in the comment above but I probably did a bad job :P
Do you have suggestions on how it might be clearer?

On 2012/12/17 05:02:23, yzshen1 wrote:

[yzshen1, 2012/12/17 05:19:37]

If my understanding is correct, it is not that it won't happen with other return
values; instead, you are making a rule and asking all resource hosts to follow
it. 

The comment sounds like "it won't happen with other return values".

On 2012/12/17 05:11:00, raymes wrote:

+  // been destroyed after this.
   reply_context.params.set_result(OnResourceMessageReceived(msg, context));
 
   // Sanity check the resource handler. Note if the result was