PPluginInstance really represents browser->plugin proxy objects, and plugin->browser proxy objects. Understandably though, it's a single protocol to keep the NPRuntime methods synchronized. I'm going to codify these rules into a state machine; the basic idea is protocol Object { both: // all NPRuntime messages start state BROWSER_OBJECT: recv ...; // only take messages from the plugin recv __delete__; start state PLUGIN_OBJECT: send ...; // only send messages from the browser send __delete__; This protocol means that upon creating a PPluginInstance, C++ must choose whether it's a BROWSER_OBJECT or PLUGIN_OBJECT, and thereafter never the twain shall meet.

Oops, brain-dead typo.

(In reply to comment #0) > protocol Object { > both: > // all NPRuntime messages > > start state BROWSER_OBJECT: > recv ...; // only take messages from the plugin > recv __delete__; > > start state PLUGIN_OBJECT: > send ...; // only send messages from the browser > send __delete__; This protocol is all wrong, because all messages *can* go both ways, except the destructor. Needs a little more thought.