Core PPAPI proxy files. This includes the dispatcher which is the control poi...

Core PPAPI proxy files. This includes the dispatcher which is the control point
on each end of the IPC channel. It includes the IPC message definitions. It
also includes the base class for the interface proxying, and the core resource
and var tracking.

BUG=none
TEST=none

Committed: http://code.google.com/p/ppapi/source/detail?r=64869

[brettw, 2010-11-01 21:34:19]

You asked for it

[jam, 2010-11-02 20:04:18]

http://codereview.chromium.org/4229002/diff/20001/21003
File ppapi/proxy/dispatcher.cc (right):

http://codereview.chromium.org/4229002/diff/20001/21003#newcode155
ppapi/proxy/dispatcher.cc:155: // Control messages.
should probably be using MessageRouter?  I just noticed it's in chrome/common,
but it should be in ipc

http://codereview.chromium.org/4229002/diff/20001/21004
File ppapi/proxy/dispatcher.h (right):

http://codereview.chromium.org/4229002/diff/20001/21004#newcode43
ppapi/proxy/dispatcher.h:43: // is where the call ends up being executed.
it would be nicer if the common functionality was in one base class, and there
were different implementations for plugin/browser sides.  that way there are no
functions that shouldn't be called depending on the usage of the object.

http://codereview.chromium.org/4229002/diff/20001/21005
File ppapi/proxy/interface_id.h (right):

http://codereview.chromium.org/4229002/diff/20001/21005#newcode12
ppapi/proxy/interface_id.h:12: // that will be sized to
to...?

http://codereview.chromium.org/4229002/diff/20001/21007
File ppapi/proxy/interface_proxy.h (right):

http://codereview.chromium.org/4229002/diff/20001/21007#newcode62
ppapi/proxy/interface_proxy.h:62: //virtual void OnMessageReceived(const
IPC::Message& msg);
why not make this pure virtual?

http://codereview.chromium.org/4229002/diff/20001/21011
File ppapi/proxy/ppapi_message_helpers.h (right):

http://codereview.chromium.org/4229002/diff/20001/21011#newcode13
ppapi/proxy/ppapi_message_helpers.h:13: 
are you sure this file will be needed later? why not add it when we have
something to put in it?

http://codereview.chromium.org/4229002/diff/20001/21014
File ppapi/proxy/ppapi_messages_internal.h (right):

http://codereview.chromium.org/4229002/diff/20001/21014#newcode15
ppapi/proxy/ppapi_messages_internal.h:15: // Loads the given plugin, returning
true on success.
what do you mean by returning?

[brettw, 2010-11-03 00:01:21]

New snap up.

http://codereview.chromium.org/4229002/diff/20001/21003
File ppapi/proxy/dispatcher.cc (right):

http://codereview.chromium.org/4229002/diff/20001/21003#newcode155
ppapi/proxy/dispatcher.cc:155: // Control messages.
I could move the message router. But I'm kind of abusing message routes for this
per-interface routing. I think we'll later move to prepopulating the interface
list since we know what the browser supports. Just using a small O(1) lookup
table for these seems simpler than generalizing and moving the message router.

http://codereview.chromium.org/4229002/diff/20001/21004
File ppapi/proxy/dispatcher.h (right):

http://codereview.chromium.org/4229002/diff/20001/21004#newcode43
ppapi/proxy/dispatcher.h:43: // is where the call ends up being executed.
I split Dispatcher into Dispatcher, PluginDispatcher, and BrowserDispatcher.

[jam, 2010-11-03 00:58:18]

lgtm

http://codereview.chromium.org/4229002/diff/60001/61002
File ppapi/proxy/browser_dispatcher.h (right):

http://codereview.chromium.org/4229002/diff/60001/61002#newcode36
ppapi/proxy/browser_dispatcher.h:36: // Constructor for the renderer side.
nit: it's a little inconsistent that the renderer side object is called
BrowserDispatcher..  That will look like it's in the browser process.  Are you
totally against RendererDispatcher?  Or even HostDispatcher?

http://codereview.chromium.org/4229002/diff/60001/61020
File ppapi/proxy/ppapi_param_traits.h (right):

http://codereview.chromium.org/4229002/diff/60001/61020#newcode6
ppapi/proxy/ppapi_param_traits.h:6: #define PPAPI_PROXY_PPAPI_PARAM_TRAITS_H_
extra space by mistake?