v0.0.3-pre.002
This commit is contained in:
129
docs/IDEAS.md
129
docs/IDEAS.md
@@ -1,8 +1,19 @@
|
||||
<!-- file: docs/IDEAS.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Idées à explorer
|
||||
|
||||
Ce document conserve les idées, pistes, questions et alternatives qui méritent d'être étudiées sans constituer encore un engagement de développement ou une décision architecturale.
|
||||
|
||||
## Statuts
|
||||
|
||||
- `À explorer`
|
||||
- `En exploration`
|
||||
- `Retenue`
|
||||
- `Rejetée`
|
||||
- `Transférée au roadmap`
|
||||
- `Transférée vers une décision/règle`
|
||||
|
||||
## APIs et extensibilité
|
||||
|
||||
### Nomenclature `*-api`
|
||||
@@ -11,38 +22,41 @@
|
||||
|
||||
Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
|
||||
|
||||
Premiers couples retenus :
|
||||
Premiers couples retenus : program, materializer et store. Les APIs worker/job sont des lifecycle APIs distinctes.
|
||||
|
||||
```text
|
||||
ksp-program-api / ksp-program-lib
|
||||
ksp-materializer-api / ksp-materializer-lib
|
||||
ksp-store-api / ksp-store-lib
|
||||
```
|
||||
### Execution policy API
|
||||
|
||||
Éviter un unique `ksp-api-lib` monolithique.
|
||||
**Status :** En exploration — candidat fort
|
||||
|
||||
### APIs workers et jobs
|
||||
Étudier `ksp-execution-policy-api` comme contrat commun d'autorisation/safety/policy d'une exécution.
|
||||
|
||||
Le contrat doit permettre des implémentations différentes selon le contexte, par exemple scenario Devnet, application générale ou futur produit trading.
|
||||
|
||||
L'UI sélectionne/injecte une implémentation réutilisable ; elle ne doit pas devenir propriétaire d'une politique complexe.
|
||||
|
||||
### Execution orchestration
|
||||
|
||||
**Status :** En exploration — candidat fort
|
||||
|
||||
Étudier `ksp-execution-lib` comme orchestration spécialisée entre programme, policy, wallet et transport, plutôt qu'une dépendance directe de `ksp-program-lib` vers wallet/transport.
|
||||
|
||||
Le graphe exact est reporté à `0.0.3-pre.003`.
|
||||
|
||||
### Scenarios : norme avant API
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
Les workers et jobs ont des modèles de lifecycle différents et ne doivent pas partager une API universelle commune.
|
||||
Ne pas créer `ksp-scenario-api` pour l'instant.
|
||||
|
||||
Prévoir séparément :
|
||||
Définir d'abord une norme souple de structure, métadonnées, exécution et résultat des crates `ksp-scenario-<domain>-lib`, sans imposer un trait Rust qui limiterait des scénarios hétérogènes.
|
||||
|
||||
```text
|
||||
ksp-worker-api
|
||||
ksp-job-api
|
||||
```
|
||||
|
||||
`ksp-worker-control-lib` reste un candidat d'implémentation de contrôle des workers uniquement.
|
||||
|
||||
Le besoin éventuel d'une implémentation commune de contrôle des jobs sera évalué séparément.
|
||||
Réévaluer seulement si les premières implémentations révèlent un vrai contrat commun.
|
||||
|
||||
### Type d'erreur KSP unique
|
||||
|
||||
**Status :** En exploration
|
||||
|
||||
La direction retenue est un seul type public `ksp_core_lib::Error` consommable par le workspace, sans obliger `ksp-core-lib` à connaître chaque domaine supérieur.
|
||||
La direction retenue est un seul type public `ksp_core_lib::Error` consommable par le workspace sans obliger `ksp-core-lib` à connaître chaque domaine supérieur.
|
||||
|
||||
### Nommage des items publics
|
||||
|
||||
@@ -54,51 +68,74 @@ Définir avec les premières APIs réelles les conventions de nommage des traits
|
||||
|
||||
**Status :** À explorer
|
||||
|
||||
Définir avec les premières crates fonctionnelles les conventions d'arborescence des modules/fichiers, façades `lib.rs`, modules API et réexports publics.
|
||||
Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades `lib.rs`, modules API et réexports publics.
|
||||
|
||||
## Données et notifications
|
||||
## Transport
|
||||
|
||||
### Notifications normalisées de données
|
||||
### Modèles homogènes on-chain
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
Une notification de donnée doit avoir la même représentation canonique pour le même type de donnée quelle que soit son origine.
|
||||
`ksp-onchain-transport-lib` ne dépend pas de `ksp-store-api`, mais ses différents providers doivent exposer des modèles homogènes par catégorie de données afin que `ksp-worker-raw-retriever` puisse les convertir simplement vers les modèles raw persistants du store.
|
||||
|
||||
`ksp-store-api` est le propriétaire candidat de ces contrats lorsque la notification signifie qu'une donnée persistée est disponible.
|
||||
Aucune `ksp-onchain-transport-api` séparée n'est prévue.
|
||||
|
||||
Le transport concret de notification reste indépendant du contrat.
|
||||
|
||||
### Backend PostgreSQL
|
||||
### Off-chain volontairement hétérogène
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
`ksp-store-lib` contient PostgreSQL comme implémentation de référence de `ksp-store-api`.
|
||||
`ksp-offchain-transport-lib` regroupe metadata, prix, quotes, routage et autres accès externes afin d'éviter une explosion de crates. Il n'est pas nécessaire de leur inventer une API métier commune.
|
||||
|
||||
## Workers et jobs
|
||||
|
||||
### W1
|
||||
### Workers de processing
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
W1 reste strictement un worker raw live/quasi-live avec reconfiguration à chaud, persistance raw et notification. Aucun replay/backfill.
|
||||
Après `ksp-worker-raw-retriever`, les responsabilités de processing actuellement prévues sont séparées :
|
||||
|
||||
### Backfill historique
|
||||
- `ksp-worker-core-processor` ;
|
||||
- `ksp-worker-generic-materializer` ;
|
||||
- `ksp-worker-domain-projector` (nom provisoire).
|
||||
|
||||
**Status :** Retenue
|
||||
### Worker control
|
||||
|
||||
Le backfill historique est un job distinct, candidat `ksp-job-backfill`.
|
||||
**Status :** Retenue comme direction
|
||||
|
||||
### Autres jobs
|
||||
`ksp-worker-control-lib` doit être une implémentation réutilisable de gouvernance consommable par des applications desktop manager, une future application globale et l'orchestrateur.
|
||||
|
||||
**Status :** Retenue
|
||||
### Job control
|
||||
|
||||
Des jobs séparés pourront apparaître pour metadata, quotes ou autres traitements ponctuels lorsqu'un besoin réel existe.
|
||||
**Status :** Rejetée pour l'instant
|
||||
|
||||
### Orchestrateur
|
||||
Ne pas créer `ksp-job-control-lib` sans duplication concrète entre plusieurs jobs. `ksp-job-api` suffit comme lifecycle API commune tant que chaque job peut être gouverné directement via son implémentation.
|
||||
|
||||
**Status :** Retenue
|
||||
## Wallet : applications futures
|
||||
|
||||
Commencer par des managers séparés. Introduire un orchestrateur global lorsque plusieurs workers/managers le justifient. Les jobs restent gouvernés par leurs contrats propres.
|
||||
### Wallet Android
|
||||
|
||||
**Status :** À explorer — futur lointain
|
||||
|
||||
Une application Android native utilisant `ksp-wallet-lib` est envisagée. Nom exact à définir plus tard, candidat : `ksp-app-wallet-android`.
|
||||
|
||||
### Extensions navigateur
|
||||
|
||||
**Status :** À explorer — futur lointain
|
||||
|
||||
Prévoir potentiellement des extensions Firefox et Chrome consommant les capacités KSP appropriées. Noms candidats non normatifs :
|
||||
|
||||
```text
|
||||
ksp-app-wallet-firefox-extension
|
||||
ksp-app-wallet-chrome-extension
|
||||
```
|
||||
|
||||
Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage des secrets devront être étudiés avant toute décision.
|
||||
|
||||
### Wallet web
|
||||
|
||||
**Status :** À explorer — futur lointain
|
||||
|
||||
Un wallet web/online utilisant les contrats KSP est envisagé. La gestion des secrets et le modèle de confiance devront être traités comme une question architecturale majeure avant développement.
|
||||
|
||||
## Pipelines
|
||||
|
||||
@@ -106,17 +143,7 @@ Commencer par des managers séparés. Introduire un orchestrateur global lorsque
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
Ne pas créer de `ksp-pipeline-lib`. Les pipelines sont introduits séparément à la demande avec un périmètre borné.
|
||||
|
||||
## Scénarios
|
||||
|
||||
### Crates spécialisées
|
||||
|
||||
**Status :** Retenue
|
||||
|
||||
Ne pas créer de `ksp-scenarios-lib` monolithique. Utiliser des crates spécialisées `ksp-scenario-<domain>-lib`.
|
||||
|
||||
Memo, Token classique, ATA et Token-2022 restent séparés. Metaplex Token Metadata et Token-2022 Metadata peuvent partager une famille metadata ; Solana Program Metadata reste séparé.
|
||||
Ne pas créer de `ksp-pipeline-lib`. Les pipelines sont introduits séparément à la demande avec un périmètre concret.
|
||||
|
||||
## Trading
|
||||
|
||||
|
||||
Reference in New Issue
Block a user