31
edits
IPDL/Getting started: Difference between revisions
m
→Basic messages
m (Forgot one PluginProtocolParent -> PPluginParent) |
m (→Basic messages) |
||
| Line 33: | Line 33: | ||
It is very important to understand message semantics. It's tempting to think of protocol messages as C++ function calls, but that's not very useful. We'll delve into gory details of the above example to illustrate these semantics. To keep the example as concrete as possible, we first need to take a detour into how the above example is translated into something that C++ code can utilize. | It is very important to understand message semantics. It's tempting to think of protocol messages as C++ function calls, but that's not very useful. We'll delve into gory details of the above example to illustrate these semantics. To keep the example as concrete as possible, we first need to take a detour into how the above example is translated into something that C++ code can utilize. | ||
The above specification will generate three headers: PPlugin.h, PPluginParent.h, and PPluginChild.h (We'll ignore the first completely; it's full of uninteresting implementation details.) As you might guess, PPluginParent.h defines a C++ class called PPluginParent. (The 'P' prefix is for 'protocol'.) This class is used in the parent actor - the browser, in this example. Similarly, code running in the plugin actor will use the PPluginChild class. | The above specification will generate three headers: PPlugin.h, PPluginParent.h, and PPluginChild.h. (We'll ignore the first completely; it's full of uninteresting implementation details.) As you might guess, PPluginParent.h defines a C++ class called PPluginParent. (The 'P' prefix is for 'protocol'.) This class is used in the parent actor - the browser, in this example. Similarly, code running in the plugin actor will use the PPluginChild class. | ||
These Parent and Child classes are abstract. They will contain a "Send" function implementation for each message type in the protocol (which derived classes can call to initiate communication), and a pure virtual "Recv" function for the message receiver. "Recv" must be implemented by the derived class. For example, the PPluginParent class will look something like the following in C++ | These Parent and Child classes are abstract. They will contain a "Send" function implementation for each message type in the protocol (which derived classes can call to initiate communication), and a pure virtual "Recv" function for the message receiver. "Recv" must be implemented by the derived class. For example, the PPluginParent class will look something like the following in C++ | ||