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:

  1. The admin is authenticated and has access to the plugin management section of the MUD server.
  2. MongoDB is available for storing plugin binaries and metadata.
  3. The server supports dynamic loading/unloading of compiled plugins.

Trigger: The admin/owner navigates to the plugin management page.


Main Success Scenario:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. 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.
  3. 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.