added plan for future stuff, roadmap.md.
This commit is contained in:
86
roadmap.md
Normal file
86
roadmap.md
Normal file
@@ -0,0 +1,86 @@
|
|||||||
|
## Roadmap
|
||||||
|
|
||||||
|
### Configuration file for persistent profiles
|
||||||
|
Save user profiles (tokens, user UUIDs, server URLs) to a local configuration file
|
||||||
|
(e.g., `~/.kvs/config.json`) that persists across shell sessions. This eliminates
|
||||||
|
the need to re-enter authentication details every time the shell starts. The file
|
||||||
|
should be stored with restricted permissions (0600) to protect sensitive token data.
|
||||||
|
Include commands like `profile save` and `profile load` to manage the persistence
|
||||||
|
layer.
|
||||||
|
|
||||||
|
### Management of local KVS instance configuration file
|
||||||
|
Provide commands to read, edit, and validate the KVS server's `config.yaml` file
|
||||||
|
directly from the shell. This would allow administrators to modify server settings
|
||||||
|
(ports, data directories, cluster secrets, feature flags) without manually editing
|
||||||
|
YAML files. Include syntax validation, preview changes before applying, and the
|
||||||
|
ability to restart the local KVS instance after configuration changes. This is particularly
|
||||||
|
useful for development and testing workflows.
|
||||||
|
|
||||||
|
### Batch operations from file
|
||||||
|
Execute multiple KVS commands from a script file, similar to SQL's source command
|
||||||
|
or MongoDB's load(). Support both sequential execution and parallel batch operations
|
||||||
|
for improved performance when uploading large datasets. Include error handling options
|
||||||
|
(continue on error vs. abort on first error) and progress reporting. This enables
|
||||||
|
data migration, testing scenarios, and automated setup workflows.
|
||||||
|
|
||||||
|
### Export/import functionality
|
||||||
|
Export entire key ranges or specific key patterns to JSON, CSV, or custom backup
|
||||||
|
formats that preserve UUIDs and timestamps. Import these files back into the same
|
||||||
|
or different KVS instances while handling conflicts appropriately. Support filtering
|
||||||
|
during export (by key prefix, timestamp range, or pattern matching) and transformation
|
||||||
|
during import (key remapping, data modification). This is critical for backup/restore
|
||||||
|
operations and cross-environment data synchronization.
|
||||||
|
|
||||||
|
### Group management commands
|
||||||
|
Implement full CRUD operations for groups through the shell: create groups, add/remove
|
||||||
|
members, list all groups, and view group details. Include commands like `group create
|
||||||
|
<name>`, `group add-member <group-uuid> <user-uuid>`, and `group members <group-uuid>`.
|
||||||
|
This complements the existing user management commands and enables complete administration
|
||||||
|
of the authorization system. Support bulk operations for adding multiple members
|
||||||
|
at once.
|
||||||
|
|
||||||
|
### Metadata management
|
||||||
|
Expose the resource metadata API (owner UUID, group UUID, permissions, TTL) through
|
||||||
|
intuitive shell commands. Allow viewing and modifying POSIX-inspired permission
|
||||||
|
bits for any key, changing ownership, and setting TTLs. Include commands like `metadata
|
||||||
|
get <key>`, `metadata set-owner <key> <user-uuid>`, and `metadata chmod <key> <permissions>`.
|
||||||
|
Display permissions in both numeric (e.g., 3840) and symbolic formats (e.g., `rwxr--r--`)
|
||||||
|
for usability.
|
||||||
|
|
||||||
|
### Query filtering and pagination
|
||||||
|
Add support for filtering keys by prefix, timestamp range, or pattern matching when
|
||||||
|
listing or searching. Implement pagination for large result sets with commands like
|
||||||
|
`list --prefix users/ --limit 50 --offset 100`. Include sorting options (by key name,
|
||||||
|
timestamp, or data fields) and output formatting (table, JSON, compact). This makes
|
||||||
|
it practical to explore and manage large datasets without overwhelming the terminal
|
||||||
|
with output.
|
||||||
|
|
||||||
|
### TLS/SSL support
|
||||||
|
Enable secure HTTPS connections to KVS servers with proper certificate validation.
|
||||||
|
Support custom CA certificates for self-signed deployments and client certificate
|
||||||
|
authentication for mutual TLS. Include commands to configure TLS settings: `tls
|
||||||
|
enable`, `tls cert <path>`, and `tls verify on/off`. Display connection security
|
||||||
|
status in the prompt (e.g., `kvs(secure)>`) to provide visual confirmation of encrypted
|
||||||
|
connections.
|
||||||
|
|
||||||
|
### Shell scripts execution
|
||||||
|
Create a scripting language or format for automating complex workflows that combine
|
||||||
|
multiple KVS operations with conditional logic and variables. Scripts could include
|
||||||
|
loops, conditionals, error handling, and variable substitution (e.g., `$UUID`, `$TIMESTAMP`).
|
||||||
|
Support both embedded scripts (via heredoc syntax) and external script files. Include a
|
||||||
|
library of common scripts for tasks like data migration, testing, and bulk updates.
|
||||||
|
|
||||||
|
### Tab completion for keys
|
||||||
|
Implement intelligent tab completion that fetches existing keys from the server
|
||||||
|
and suggests completions as you type. Cache key prefixes locally to minimize server
|
||||||
|
requests while typing. Support completion for key paths (e.g., typing `users/a<tab>`
|
||||||
|
would suggest `users/alice`, `users/admin`). Include fuzzy matching and recent key
|
||||||
|
history to speed up navigation of frequently accessed keys.
|
||||||
|
|
||||||
|
### Transaction support
|
||||||
|
Provide multi-key atomic operations through a transaction API, allowing users to
|
||||||
|
group multiple get/put/delete operations that either all succeed or all fail together.
|
||||||
|
Use syntax like `begin`, `commit`, and `rollback` commands to demarcate transaction
|
||||||
|
boundaries. Support read-your-writes consistency within a transaction and optimistic
|
||||||
|
concurrency control with conflict detection. This would require backend support
|
||||||
|
for transactions, which may need to be implemented in the KVS server first.
|
Reference in New Issue
Block a user