202 lines
7.7 KiB
Plaintext
202 lines
7.7 KiB
Plaintext
---
|
|
description: Outlines the technical architecture of the PlugSnatcher application, providing an overview of the system design, component interactions, and data flow.
|
|
globs:
|
|
alwaysApply: false
|
|
---
|
|
## System Overview
|
|
|
|
PlugSnatcher is a desktop application built using Tauri, combining a Rust backend with a React/TypeScript frontend:
|
|
|
|
- **Frontend**: React + TypeScript for the user interface
|
|
- **Backend**: Rust for file system operations and plugin analysis
|
|
- **Bridge**: Tauri for integration between frontend and backend
|
|
|
|
## Architecture Diagram
|
|
|
|
```
|
|
+------------------------------------+ +------------------------------------+
|
|
| FRONTEND | | BACKEND |
|
|
| (React + TypeScript) | | (Rust) |
|
|
| | | |
|
|
| +----------------------------+ | | +----------------------------+ |
|
|
| | Components | | | | Core Functions | |
|
|
| | | | | | | |
|
|
| | - App.tsx | | | | - Plugin Scanner | |
|
|
| | - ServerInfoDisplay | | | | - Metadata Extractor | |
|
|
| | - PluginDetails |<---|------|->| - Server Type Detector | |
|
|
| | | | | | - Hash Calculator | |
|
|
| +----------------------------+ | | +----------------------------+ |
|
|
| | | |
|
|
| +----------------------------+ | | +----------------------------+ |
|
|
| | State Management | | | | Data Models | |
|
|
| | | | | | | |
|
|
| | - useState Hooks | | | | - Plugin | |
|
|
| | - Future Context API |<---|------|->| - ServerInfo | |
|
|
| | | | | | - PluginMeta | |
|
|
| +----------------------------+ | | +----------------------------+ |
|
|
| | | |
|
|
+------------------------------------+ +------------------------------------+
|
|
^ ^
|
|
| |
|
|
| Tauri Bridge |
|
|
| |
|
|
v v
|
|
+------------------------------------+ +------------------------------------+
|
|
| EXTERNAL SERVICES | | FILESYSTEM ACCESS |
|
|
| | | |
|
|
| - Web Crawler | | - Server Directory |
|
|
| - Plugin Repositories API | | - Plugin JAR Files |
|
|
| - Update Detection | | - Configuration Files |
|
|
| | | |
|
|
+------------------------------------+ +------------------------------------+
|
|
```
|
|
|
|
## Component Breakdown
|
|
|
|
### Frontend (React + TypeScript)
|
|
|
|
1. **Main Components**:
|
|
- `App`: The main application component that orchestrates the UI
|
|
- `ServerInfoDisplay`: Displays information about the Minecraft server
|
|
- `PluginDetails`: Shows detailed information about a selected plugin
|
|
|
|
2. **State Management**:
|
|
- Currently uses React's `useState` for local component state
|
|
- Future: May implement Context API for global state as app complexity grows
|
|
|
|
3. **Frontend Services**:
|
|
- Tauri invoke calls to the Rust backend
|
|
- UI state management
|
|
- Event handling
|
|
- Future: Web service integration
|
|
|
|
### Backend (Rust)
|
|
|
|
1. **Core Modules**:
|
|
- `Plugin Scanner`: Scans directories for plugin JAR files
|
|
- `Metadata Extractor`: Extracts plugin.yml data from JAR files
|
|
- `Server Type Detector`: Identifies the Minecraft server type
|
|
- `Hash Calculator`: Generates SHA-256 hashes for plugin files
|
|
|
|
2. **Data Models**:
|
|
- `Plugin`: Represents a Minecraft plugin with its metadata
|
|
- `ServerInfo`: Contains information about the server type and configuration
|
|
- `PluginMeta`: Raw metadata extracted from plugin files
|
|
- `ScanResult`: Combined result of a server scan operation
|
|
|
|
3. **Command API**:
|
|
- `scan_server_directory`: Scans a server for plugins and server information
|
|
- Future: Commands for update checking, plugin installation, etc.
|
|
|
|
## Data Flow
|
|
|
|
1. **User Initiates Server Scan**:
|
|
```
|
|
UI Action -> Frontend Event Handler -> Tauri Invoke -> Rust Command ->
|
|
Filesystem Access -> Plugin Analysis -> Result Serialization ->
|
|
Frontend State Update -> UI Rendering
|
|
```
|
|
|
|
2. **Plugin Detail View**:
|
|
```
|
|
Plugin Selection -> State Update -> UI Component Rendering
|
|
```
|
|
|
|
3. **Future: Plugin Update Process**:
|
|
```
|
|
Update Check -> Web API Call -> Compare Versions ->
|
|
UI Notification -> User Confirmation -> Download ->
|
|
Backup Original -> Replace Plugin -> Refresh UI
|
|
```
|
|
|
|
## Database/Storage
|
|
|
|
Current implementation uses in-memory state with no persistence. Future versions will implement:
|
|
|
|
1. **Local Storage Options**:
|
|
- SQLite database for plugin metadata and scan history
|
|
- JSON file storage for configuration and preferences
|
|
- Filesystem for plugin backups
|
|
|
|
2. **Data Schema** (Planned):
|
|
```
|
|
Servers
|
|
- ServerID
|
|
- ServerPath
|
|
- ServerType
|
|
- LastScan
|
|
|
|
Plugins
|
|
- PluginID
|
|
- ServerID (FK)
|
|
- Name
|
|
- Version
|
|
- FilePath
|
|
- FileHash
|
|
- LastUpdated
|
|
|
|
Updates
|
|
- UpdateID
|
|
- PluginID (FK)
|
|
- AvailableVersion
|
|
- ReleaseDate
|
|
- ChangelogURL
|
|
```
|
|
|
|
## Security Considerations
|
|
|
|
1. **File System Access**:
|
|
- Limited to reading plugin directories and JAR files
|
|
- No modification of server files without explicit permission
|
|
|
|
2. **Network Security** (Future):
|
|
- Verification of downloaded plugins via checksums
|
|
- HTTPS for all external API communications
|
|
- Sandboxed plugin downloads
|
|
|
|
3. **Error Handling**:
|
|
- Graceful error recovery
|
|
- User-friendly error messages
|
|
- Detailed error logging
|
|
|
|
## Scalability Considerations
|
|
|
|
1. **Performance Optimizations**:
|
|
- Asynchronous plugin scanning for large server directories
|
|
- Caching of plugin metadata to reduce repeated JAR parsing
|
|
- Incremental updates of the plugin list
|
|
|
|
2. **Modularity**:
|
|
- Design for extensibility with new features
|
|
- Clear separation between UI and business logic
|
|
- Modular crawler system for multiple plugin sources
|
|
|
|
## Future Architecture Extensions
|
|
|
|
1. **Plugin Update System**:
|
|
- Web crawler for multiple plugin repositories
|
|
- Version comparison engine
|
|
- Plugin download and installation manager
|
|
|
|
2. **Server Management**:
|
|
- Multiple server profile support
|
|
- Server start/stop controls
|
|
- Configuration file editing
|
|
|
|
3. **Enhanced UI**:
|
|
- Dashboard with server health metrics
|
|
- Plugin conflict detection
|
|
- Compatibility matrix
|
|
|
|
## Development Environment
|
|
|
|
- **Frontend**: Node.js, npm, TypeScript, React
|
|
- **Backend**: Rust, Cargo
|
|
- **Build System**: Tauri CLI
|
|
- **Deployment**: Self-contained executables for Windows (primary), potentially macOS and Linux
|
|
|
|
## Conclusion
|
|
|
|
This architecture provides a solid foundation for the PlugSnatcher application while allowing for scalability and future enhancements. The separation of concerns between the frontend and backend ensures that each part can evolve independently while maintaining a coherent system.
|
|
|
|
As the application grows, this document should be updated to reflect architectural changes and new components. |