Add resource message call and reply infrastructure.

Add resource message call and reply infrastructure.

These messages are not yet used. They will allow us to route messages directly to a resource implementation in the proxy or the host using information in a common header. The actual content of the message (as interpreted by the specifi resource in the plugin or class in the host) is a nested message.

TEST=none
BUT=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=143463

[brettw, 2012-06-18 04:34:48]

Low priority. This is a isolated piece cleaved off of my bigger patch that
contains the messages and related infrastructure.

[bbudge, 2012-06-18 17:23:47]

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
File ppapi/proxy/ppapi_messages.h (right):

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1392: // New-style resource call/reply messages.
A more informative comment about the idea of resource call/reply messages and
nested messages would be helpful here.

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1394: // Notification that the a resource has been
created in the plugin. The nested
s/the a/a/

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1401: // Notificaition that a resource has been
destroyed in the plugin.
sp. Notification

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1412: // A resource reply is a response from a
ResourceCall from a host to the
s/response from/response to

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1414: // that of a previous ResourceCall.
A "previous" ResourceCall or the one that this is replying to?

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
File ppapi/proxy/resource_message_params.h (right):

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.h:15: // Common parameters for call and
reply params.
// Common parameters for resource call and reply messages ?

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.h:44: // confusion within the plugin and
within callbacks on the same resoruce,
sp. resource

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.h:68: static const unsigned kFlagHasCallback
= 1 << 0;
I'm wondering why this isn't just a bool. Will there be more flags? Since this
is private, it won't be possible for derived classes to define their own flags.

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.h:95: 
Is it typical for components that use IPC to put their param types into the IPC
namespace?

[brettw, 2012-06-18 17:33:53]

Thanks, will address your other comments tonight.

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
File ppapi/proxy/resource_message_params.h (right):

https://chromiumcodereview.appspot.com/10560030/diff/2001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.h:95: 
This is a template specialization so it has to be in the same namespace as the
original template.

[brettw, 2012-06-19 05:08:20]

I think I got everything, PTAL

[bbudge, 2012-06-19 20:40:31]

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/proxy/ppapi_m...
File ppapi/proxy/ppapi_messages.h (right):

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/proxy/ppapi_m...
ppapi/proxy/ppapi_messages.h:1396: // host object.
Maybe a little explanation about 'nesting'? Which message is nested in which. Or
is nesting an existing concept that is explained somewhere else?

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/proxy/resourc...
File ppapi/proxy/resource_message_params.cc (right):

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.cc:40: flags_(0) {
Compiler says this isn't a field anymore.

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/proxy/resourc...
ppapi/proxy/resource_message_params.cc:46: flags_(0) {
Ditto

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/shared_impl/s...
File ppapi/shared_impl/scoped_pp_var.cc (right):

https://chromiumcodereview.appspot.com/10560030/diff/8001/ppapi/shared_impl/s...
ppapi/shared_impl/scoped_pp_var.cc:32: }
I don't see how the input var loses its ref. Am I misunderstanding the
semantics?

[brettw, 2012-06-20 15:37:47]

New patch up. The scoped var stuff in the last patch was actually from a
different change, sorry for the confusion. I addressed your other comments.

[bbudge, 2012-06-20 16:58:41]

LGTM w/optional suggestion

https://chromiumcodereview.appspot.com/10560030/diff/11002/ppapi/proxy/resour...
File ppapi/proxy/resource_message_params.cc (right):

https://chromiumcodereview.appspot.com/10560030/diff/11002/ppapi/proxy/resour...
ppapi/proxy/resource_message_params.cc:61: return
IPC::ParamTraits<bool>::Read(msg, iter, &has_callback_);
Could be:
return ResourceMessageParams::Deserialize(msg, iter) &&
          IPC::ParamTraits<bool>::Read(msg, iter, &has_callback_);

also below.

[commit-bot: I haz the power, 2012-06-21 17:33:03]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brettw@chromium.org/10560030/11002

[commit-bot: I haz the power, 2012-06-21 21:46:27]

Change committed as 143463