|
Note: This is not working fully yet. A server restart is the only way to guarantee a proper reload today.
Extensions support the ability to dynamically reload if any changes are made to the contents of the extension directory. Reloading an extension is a multi-step process that warrants a more detailed description.
| 1. | The server scans the extension directory looking for changes to existing extensions or newly added extensions. |
| 2. | If a change is found, the server rescans the extension on short intervals waiting for changes to settle out. This is to prevent an extension from being deployed while it is still being copied. |
| 3. | The extension is copied into the server’s temporary directory. If the extension is zipped up currently, it is extracted during the copy. |
| 4. | If the extension is a duplicate of an existing extension, the existing extension is shut down via the process described previously. To ensure the integrity of the system and prevent data mismatch problems with the new extension, some users must be disconnected, according to the following rules: |
| • | Any user that has gone through a login event handler associated with this extension is disconnected. This is to ensure that they will be forced to login through the newly deployed extension. |
| • | Any user that has had an associated extension-bound user-server-variable via the extension will be disconnected. This is necessary because these users could have had an object associated with them that may not be compatible with the new extension code base. |
| • | Any user that is in a room and has a room-level plug-in from the extension will be kicked from the room and the room will be destroyed. This is to ensure the room can be re-created with the new code. |
| 4. | The new extension is started up using the procedure described above. |
|