District Core pour Rust

Le noyau Rust que partagent les applications District AI pour Linux et Windows : les types de données, le client HTTP, la connexion, les mises à jour en direct, l'état de l'application et le moteur d'appel, en sept crates sans aucune boîte à outils d'interface. Une application affiche l'état que le noyau lui remet et transmet ce que fait l'utilisateur; le noyau décide du reste.

Utilisé par

District AI pour LinuxGTK 4 et libadwaita

District AI pour WindowsWinUI 3, par UniFFI

Sept crates, un seul espace de travail

district-modelLes types de données de l'API et les enveloppes des événements en direct, sans entrée-sortie

district-apiLe client HTTP et la table des points d'accès

district-authLa connexion : OAuth avec PKCE dans le navigateur, le renouvellement des jetons, la déconnexion

district-liveLe canal des mises à jour en direct

district-coreL'état de l'application : la session, les routes, un modèle par écran, l'exécuteur d'effets

district-hostCe qu'une application de bureau garde sur l'ordinateur, et la mise en veille

district-callLe moteur d'appel, sur LiveKit dans une version avec les appels

Testé sous Linux et Windows.

Un seul noyau pour les applications de bureau

Testé sans bureau

Aucune crate ne dépend d'une boîte à outils d'interface ni d'un seul système d'exploitation : chaque test s'exécute sans écran, sans trousseau et sans réseau, sous Linux comme sous Windows. Les tests doivent atteindre chaque ligne de la version par défaut de chaque crate, sinon l'intégration continue échoue.

Vérifié contre les réponses du service

Le dépôt contient des réponses enregistrées du service District AI, et ses tests les décodent toutes en refusant les champs inconnus : un champ que le serveur renomme ou ajoute fait échouer les tests ici plutôt que dans une application. La table des points d'accès est comparée chaque semaine à celle de l'application Android.

Un changement arrive dans une application par une version

Une publication est une étiquette de version qui ne bouge jamais. Chaque application la fixe par étiquette et par version exacte, si bien que Cargo refuse une étiquette qui ne contient pas cette version, et passe à une nouvelle publication dans une demande de fusion distincte.

Licence: Apache-2.0
Construit avec: Rust, Cargo
Utilisé par: District AI pour Linux et District AI pour Windows

District Core pour Rust sur GitHub

Ce qui est à code source ouvert, et ce qui ne l'est pas

Ce qui est à code source ouvert

Ces crates, sous licence Apache 2.0 : vous pouvez les lire, les compiler, les modifier et les utiliser. Les noms, les logos et les icônes d'application District AI et Distronode sont des marques de commerce : une application que vous distribuez avec ces crates porte donc son propre nom, sa propre icône et son propre identifiant.

Les crates ne signalent aucun plantage : aucune bibliothèque de signalement des plantages ne figure parmi leurs dépendances, et rien en elles n'écrit de journal ni n'affiche quoi que ce soit.

Ce qui ne l'est pas

Le service District AI avec lequel les crates communiquent. La connexion exige un compte District AI; sans compte, vous pouvez quand même compiler les crates et exécuter tous les tests.

Sans compte chez nous

Aujourd'hui, les applications ont besoin d'un compte District AI pour se connecter. Nous voulons qu'elles fonctionnent aussi sans compte chez nous. Nous n'avons pas encore établi à quoi cela ressemblerait, ni si c'est faisable, et la réponse dépend de ce à quoi les gens voudraient les relier : nous posons donc la question avant de construire quoi que ce soit. La discussion est en anglais, mais vous pouvez y écrire en français.

Dites-nous à quoi vous les relieriez

Participer

Les tickets et les demandes de fusion sont les bienvenus sur GitHub. Signalez une vulnérabilité en privé, comme l'indique la politique de sécurité, et non dans un ticket public.

Guide de contribution: CONTRIBUTING.md
Politique de sécurité: SECURITY.md
Journal des modifications: CHANGELOG.md