Use Case: Plugin Management System for Labyrinth MUD Server - wwestlake/Labyrinth GitHub Wiki
Use Case: Plugin Management System for Labyrinth MUD Server
Goal: Provide an interface for the admin/owner to manage plugins in the Labyrinth MUD server. This includes enabling/disabling plugins, managing running states, editing source code, compiling plugins, and handling multiple versions with version control.
Use Case: Manage and Edit Plugins
Primary Actor: Labyrinth MUD Server Admin/Owner
Scope: Labyrinth MUD Admin Web Application
Preconditions:
- The admin is authenticated and has access to the plugin management section of the MUD server.
- MongoDB is available for storing plugin binaries and metadata.
- The server supports dynamic loading/unloading of compiled plugins.
Trigger: The admin/owner navigates to the plugin management page.
Main Success Scenario:
-
View Installed Plugins:
- The admin sees a list of all installed plugins, with a name, description, and state indicators (enabled/disabled, running/stopped).
Tech Requirements:
- Frontend: JavaScript/React for displaying the plugin list.
- Backend: REST API to retrieve plugin data from MongoDB.
- Database: MongoDB for storing plugin metadata (e.g., name, description, state, versions).
-
Change Plugin Status:
- The admin clicks to enable/disable a plugin.
- For plugins that support background tasks, the admin can start/stop them.
Tech Requirements:
- Frontend: State management and UI interactions for toggling enabled/disabled or started/stopped modes.
- Backend: REST API to update the plugin's status in MongoDB and apply changes in the running server.
- Server: Plugin management service to dynamically enable/disable/start/stop plugins.
-
Edit Plugin Source Code:
- The admin selects a plugin and opens the F# source code in a web-based code editor with syntax highlighting and suggestions.
- The admin makes changes and submits them back to the server.
Tech Requirements:
- Frontend: Code editor component (e.g., Monaco Editor or ACE) with F# syntax highlighting and IntelliSense.
- Backend: REST API to retrieve the current source code from MongoDB and send back changes.
- Compiler: F# Compiler integration to recompile the plugin after changes.
-
Compile Plugin:
- Upon saving changes, the server recompiles the plugin.
- If the compilation fails, the admin sees a list of errors with line numbers.
- If successful, the new plugin version is saved in MongoDB with appropriate metadata, including a rolling build number, timestamp, and user who made the change.
Tech Requirements:
- Backend: REST API to trigger compilation and return results (errors or success).
- Compiler: F# Compiler to compile the plugin and return diagnostics.
- Database: MongoDB to store compiled plugin binaries and metadata, including version history.
-
Version Control for Plugins:
- The admin sees an indicator if a plugin has multiple versions.
- The admin can list all versions, including metadata like build number, description, compilation date, and the user who made the changes.
- The admin can choose to delete or purge older versions.
Tech Requirements:
- Frontend: UI to display version history and allow actions like purging old versions.
- Backend: REST API to retrieve version history and delete old versions.
- Database: MongoDB to store multiple versions of plugins, including metadata.
Alternative Flows:
-
Compile Failure (Error List):
- If the plugin fails to compile, the server returns a list of compilation errors.
- The admin can review and fix the code in the web editor before trying again.
Tech Requirements:
- Backend: Error handling in the F# compiler service and a mechanism to return structured error data.
- Frontend: Display error messages in the code editor.
Non-Functional Requirements:
- Performance: Compiling and loading plugins should be quick, and the UI must remain responsive.
- Security: Only authenticated admins should be able to modify plugins. Compilation should be sandboxed to prevent execution of malicious code.
- Scalability: MongoDB should efficiently handle multiple versions of plugins and maintain performance as the number of plugins grows.
- Resilience: The system should handle cases where plugins fail to compile or load without affecting the stability of the MUD server.
Technical Breakdown:
-
Frontend (Web UI):
- JavaScript/React: To build the plugin management interface, state toggles, and version control UI.
- Code Editor Component: For syntax-highlighted, real-time F# code editing (e.g., Monaco or ACE Editor).
- API Integration: Communicate with the backend to manage plugins, handle compilation, and display errors.
-
Backend:
- REST API: Expose endpoints for plugin management (list, enable/disable, start/stop, compile, edit source, etc.).
- F# Compiler Service: Integrate the F# compiler to dynamically compile code and handle errors or successful builds.
- Plugin Loader: Implement a service to load/unload plugins dynamically based on their state and compilation results.
-
Database (MongoDB):
- Plugin Metadata Storage: Store plugin details (name, description, enabled/disabled, running/stopped state, version history).
- Binary Storage: Store compiled plugin binaries as binary objects or using MongoDB’s GridFS for larger plugins.
- Versioning: Maintain a version history for each plugin, with metadata such as build number, description, and timestamps.
Postconditions:
- The admin has successfully enabled/disabled or started/stopped a plugin.
- The admin has edited the source code of a plugin and either compiled it successfully or seen errors in the editor.
- The plugin's new version, if compiled, has been stored in MongoDB with metadata.
- The admin has viewed and managed the version history of a plugin.
This use case defines the end-to-end flow for managing plugins in the Labyrinth MUD system, from viewing and modifying plugins to compiling and versioning them.