The PowerWeb Master application is responsible for task mapping, code transmission and reconciliation of results returning from each connected PowerWeb Slave.
PowerWeb Master was designed from the outset to be multi-threaded. This separated logical areas which eased development. The threads used in master are:
This handles all general user interface such as menuing and window management. This can be thought of as the generic application-type activities.
The results thread receives results returning from completed tasks and determines which plug-in the result is routed to. Results need not (and often won't) come back in the same order they were sent out.
The preferences thread periodically scans the preferences folder. This is used to keep track of the current plug-in folder location which can be changed at anytime by the user. One use of switching plug-in folders is that it allows different sets of plug-ins for different types of work.
The plug-in thread was designed to scan the plug-in folder periodically. This maintains all the proper plug-ins on the plug-in folder menu. At any time plug-ins may be added, deleted, or even updated with new plug-ins having duplicate filenames. All cases are handled transparently by this thread. Also when a new plug-in folder is selected all the current plug-ins are shutdown and those in the newly selected folder are dynamically linked into the system.
This asynchronously searches for other masters on the network. This way the user does not have to wait for the search to complete before the application can be used.
This thread keeps the main-event-loop thread from halting during the time that modal dialogs are being displayed. By doing this the Apple Event communication system will not time out.
Plug-ins can be installed or de-installed at any time. To install a plug-in into PowerWeb, the user simply drags the plug-in file to the Plug-Ins folder. PowerWeb Master notices that a new file is there, and ensures that it's properly initialized. Similarly, simply dragging the plug-in file out of the Plug-Ins folder makes PowerWeb Master notice that the plug-in file is gone and PowerWeb Master performs appropriate shutdown operations on that plug-in.
Although PowerWeb uses a simple Master-Slave architecture for performing distributed tasks, the actual relationship can be more complex. More than one PowerWeb Master may be active simultaneously while connected to the same Slaves; the total picture is that of a "pool" of PowerWeb Slaves and any PowerWeb Master may access any of them. PowerWeb Master thus has mechanisms to communicate between Masters to ensure that each Master knows about the other Master's Slaves.
Much of Master's function is supporting (potentially third-party) plug-ins. In order to maintain ease of development for thirds parties, PowerWeb Master must go through a lot of complexity to ensure that everything behaves as desired. For example, see Appendix Two for a description of a patch to the GetResource() trap.