|
1 | 1 | # Grumpy IO |
2 | 2 |
|
3 | | -Full IO mapping for Grumpy applications, providing a unified API for file system access, networking, and local storage across all platforms. |
4 | | - |
5 | | -## Modules |
6 | | - |
7 | | -- [ ] File System Module |
8 | | - - [ ] File System CRUD operations |
9 | | - - [ ] File Picker |
10 | | - - [ ] Filesystem Watcher |
11 | | - - [ ] File Metadata Extraction |
12 | | -- [ ] Networking Module |
13 | | - - [x] Network Requests |
14 | | - - [ ] Typed Response parsing via datasources |
15 | | - - [ ] WebSocket Support |
16 | | - - [ ] Network Connectivity Monitoring |
17 | | - - [ ] Data Streaming |
18 | | - - [ ] Downloading, with progress tracking |
19 | | - - [ ] Uploading, with progress tracking |
20 | | -- [ ] Local Storage |
21 | | - - [ ] App Directories |
22 | | - - [ ] Temporary Directory/temp files |
23 | | - - [ ] Persistent Directory |
24 | | - - [ ] Cache Directory |
25 | | - - [ ] Cookies |
26 | | -- [ ] Process management (desktop only, noop for web and mobile) |
27 | | - - [ ] Spawn processes |
28 | | - - [ ] Inter-process communication (IPC) |
29 | | - - [ ] Process monitoring and control |
30 | | - - [ ] Force single app instance |
31 | | - - [ ] Run shell commands |
32 | | - - [ ] Command line argument parsing (via config) |
33 | | -- [ ] System information |
34 | | - - [ ] OS details |
35 | | - - [ ] Hardware specifications |
36 | | - - [ ] Environment variables |
| 3 | +`grumpy_io` provides cross-platform IO services and typed datasource adapters for Grumpy apps. |
| 4 | + |
| 5 | +It covers: |
| 6 | +- raw networking |
| 7 | +- raw filesystem |
| 8 | +- persistent local storage |
| 9 | +- typed datasource wrappers in each owning module |
| 10 | +- optional Grumpy cache/persistence compatibility adapters |
| 11 | + |
| 12 | +## Design Goals |
| 13 | + |
| 14 | +- Keep public IO contracts backend-agnostic. |
| 15 | +- Return typed `IoResult<T>` instead of leaking backend exceptions. |
| 16 | +- Keep typed datasources close to their owning module. |
| 17 | +- Use compile-time platform selection for platform-specific services. |
| 18 | + |
| 19 | +## Module Layout |
| 20 | + |
| 21 | +### Networking Module |
| 22 | + |
| 23 | +Exports: |
| 24 | +- `NetworkService` |
| 25 | +- `FileTransferService` |
| 26 | +- `TypedNetworkDatasource` |
| 27 | + |
| 28 | +Default implementations: |
| 29 | +- `DioNetworkService` |
| 30 | +- `DefaultFileTransferService` |
| 31 | +- `DefaultTypedNetworkDatasource` |
| 32 | + |
| 33 | +### File System Module |
| 34 | + |
| 35 | +Exports: |
| 36 | +- `FileSystemService` |
| 37 | +- `TypedFileSystemDatasource` |
| 38 | +- `IoPath`, `FsMetadata`, `FsEntityType` |
| 39 | + |
| 40 | +Default implementations: |
| 41 | +- `DefaultFileSystemService` (platform-selected) |
| 42 | +- `DefaultTypedFileSystemDatasource` |
| 43 | + |
| 44 | +### Local Storage Module |
| 45 | + |
| 46 | +Exports: |
| 47 | +- `LocalStorageService` |
| 48 | +- `TypedLocalStorageDatasource` |
| 49 | +- `LocalStorageKey`, `LocalStorageValue` |
| 50 | + |
| 51 | +Default implementations: |
| 52 | +- `DefaultLocalStorageService` (platform-selected) |
| 53 | +- `DefaultTypedLocalStorageDatasource` |
| 54 | + |
| 55 | +Persistence behavior: |
| 56 | +- Native (`io`): persisted via `FileSystemService` in a JSON file. |
| 57 | +- Web: persisted in browser `localStorage` with cookie fallback. |
| 58 | + |
| 59 | +## Typed Datasources |
| 60 | + |
| 61 | +Typed datasources are intentionally colocated with their modules: |
| 62 | +- networking typed datasource lives in networking module |
| 63 | +- filesystem typed datasource lives in filesystem module |
| 64 | +- local-storage typed datasource lives in local-storage module |
| 65 | + |
| 66 | +Shared typed datasource concerns are in `shared_module`. |
| 67 | + |
| 68 | +## Platform-Specific Service Convention |
| 69 | + |
| 70 | +For services with platform-specific implementations: |
| 71 | +- platform files live under `<module>/infra/services/<service>/...` |
| 72 | +- an entrypoint file performs conditional export |
| 73 | +- concrete platform implementations expose the same symbols |
| 74 | + |
| 75 | +Example pattern: |
| 76 | + |
| 77 | +```dart |
| 78 | +export 'service_stub.dart' |
| 79 | + if (dart.library.io) 'service_io.dart' |
| 80 | + if (dart.library.js_interop) 'service_web.dart'; |
| 81 | +``` |
| 82 | + |
| 83 | +## Error Model |
| 84 | + |
| 85 | +All public IO surfaces use: |
| 86 | +- `IoResult<T>` |
| 87 | +- `IoOk<T>` |
| 88 | +- `IoErr<T>` |
| 89 | +- `IoFailure` with `IoFailureCode` |
| 90 | + |
| 91 | +This keeps consumers on one stable error contract across backends/platforms. |
| 92 | + |
| 93 | +## Grumpy Compatibility Layer |
| 94 | + |
| 95 | +`grumpy_compat` provides optional adapters for: |
| 96 | +- memory cache layer |
| 97 | +- persistent cache layer |
| 98 | +- cache pipeline |
| 99 | +- repo snapshot persistence |
| 100 | +- root module mixin wiring |
| 101 | + |
| 102 | +## Public Exports |
| 103 | + |
| 104 | +Package root exports: |
| 105 | +- `core` |
| 106 | +- `networking_module` |
| 107 | +- `file_system_module` |
| 108 | +- `local_storage_module` |
| 109 | +- `grumpy_compat` |
| 110 | +- `grumpy_io_module` |
| 111 | + |
| 112 | +## Status |
| 113 | + |
| 114 | +Current focus is V1 core IO and persistence surfaces. Process-management and system-information features remain out of scope for V1. |
0 commit comments