#Module ubf_plugin_handler#
Implement the plugin server, an intermediate process between the contract manager process and the server application.
The server application may or may not have a separate process (see the diagram below). The there is no application process(es), then the remote procedure call will be executed by the process executing this module\'s +loop()+ function.
This module also implements the plugin manager loop.
.
##Function Index##
| ask_manager/2 | |
| install_default_handler/1 | Install a default handler function (callback-style) for asynchronous UBF messages. The default handler function, drop_fun/1, does nothing. . |
| install_handler/2 | Install a handler function (callback-style) for asynchronous UBF messages. The handler fun Fun should be a function of arity 1. When an asynchronous UBF message is received, the callback function will be called with the UBF message as its single argument. The Fun is called by the ubf plugin handler process so the Fun can crash and/or block this process. If your handler fun must maintain its own state, then you must use an intermediate anonymous fun to bind the state. See the usage of the +irc_client_gs:send_self/2+ fun as an example. The +send_self()+ fun is actually arity 2, but the extra argument is how the author, Joe Armstrong, maintains the extra state required to deliver the async UBF message to the process that is executing the event loop processing function, +irc_client_gs:loop/6+. . |
| manager/3 | |
| sendEvent/2 | Send an asynchronous UBF message. . |
| start_handler/5 | |
| start_manager/2 |
##Function Details##
###ask_manager/2##
ask_manager(Manager::pid(), Call::term()) -> Reply::term()
###install_default_handler/1##
install_default_handler(Handler::pid()) -> ack
Install a default handler function (callback-style) for asynchronous UBF messages.
The default handler function, drop_fun/1, does nothing.
###install_handler/2##
install_handler(Handler::pid(), Fun::function()) -> ack
Install a handler function (callback-style) for asynchronous UBF messages.
The handler fun Fun should be a function of arity 1. When an asynchronous UBF message is received, the callback function will be called with the UBF message as its single argument. The Fun is called by the ubf plugin handler process so the Fun can crash and/or block this process.
If your handler fun must maintain its own state, then you must use an intermediate anonymous fun to bind the state. See the usage of the +irc_client_gs:send_self/2+ fun as an example. The +send_self()+ fun is actually arity 2, but the extra argument is how the author, Joe Armstrong, maintains the extra state required to deliver the async UBF message to the process that is executing the event loop processing function, +irc_client_gs:loop/6+.
###manager/3##
manager(ExitPid, Mod, Args) -> any()
###sendEvent/2##
sendEvent(Handler::pid(), Cast::term()) -> ok | no_return()
Send an asynchronous UBF message.
###start_handler/5##
start_handler(MetaMod, Mod, Server, StatelessRPC, SpawnOpts) -> any()
###start_manager/2##
start_manager(Mod, Args) -> any()